Hi Robert,
Just because we use VS doesn't mean that we have to do everything the
MS way. The MS way is to code everything for Windows and Windows
only, cares for portability are very much against MS's strategic goals
of vendor lock-in. Play their game and you end up tied to just a
single platform and benefiting that vendor rather than your customers.
Oh come on. Aren't you pushing this a bit too far? We're not playing
anyone's game, just using a tool that allows us to compile code on a
given platform. This platform choice (which is only one option, we
support Linux too, but cannot go away from Windows completely) is
dictated by our clients and past history. That's what's locking us into
using that tool, not the tool itself.
Even if I were working on personal projects only, I would still advocate
for OSG to support VS in the best way possible. It's too big a market
and a user base to push to the wayside and have half-baked support for.
The add something sometimes, so you have to review them all carefully
and them make a judgement call, once you've made that judgement call
and it's clear the code is correct, and the warning misleading then
you have to then look at quashing it, but only then.
Again, the judgement call only applies to one situation (OSG). Others
should be free to make another judgement call depending on their situation.
Don't forget that even the include/osg/Export pragam's can be switched
off via CMake so you can easily do a periodic double check to see if
any of the warnings point to some genuine problem.
But then even OSG's headers will generate warnings. A library should not
generate warnings, but should not obscure the warnings in your own code.
Period. Do you at least agree with that?
Goodness, this is pretty long departure from having clean Standard C++
headers... Adding two header includes to our headers just to quieten
down warnings on one specific compiler set, or one specific platform
so everyone pays for the convenience of one platform.
As Matthew said, this could be replaced by macros in a single header, or
something else. As I said, I was trying to suggest something, anything,
in the hope we could go forward in some way. Just arguing back and forth
doesn't help anything, so I think I'll stop replying about this subject
if we don't go forward at least a bit.
What happens if
you forgot to add the closing HeaderEnd??
What happens if I forget to add #endif to the end of a header to close
the include guards? That's not standard C++ either, just common
practice, and no one really fights that.
What happens if you miss
the beginning one? Yep the push/pop won't balance. If I make such a
mistake ut wont' effect me working under unix, I won't even spot it,
but port my problem code to windows and bang lots of odd problems.
Well, since you don't even see the VS warnings, and don't see errors
related to OSG_EXPORT, and don't see... I don't understand how that's
worse. Someone (probably me, lucky as I am) will compile on Windows, see
the error, track it to the missing end marker (whatever that may be) and
submit the fix, the same as a missing OSG_EXPORT. For the number of
times a new header is added to OSG, I think it's really minor.
This certainly won't make help code portability and maintainability.
Let's just suppress all warnings in osg/Export then, and see if users
like that. (I'm only partly joking)
Anyways, the basic premise I'm maintaining is that
a) a library should not cause any warnings when including its headers in
user code
b) a library should not suppress warnings caused by user code
If you don't agree with that, then I'll let go, because suppressing
*some* warnings in osg/Export is probably the best middle ground I'm
likely to get.
J-S
