Hi Guys,
I generally agree that suppressing these warnings is bad. Truth is if they
were not disabled at the early days of OSG most of them would be not present
today because authors would fix them in other way. And this poses a danger
for the future. As along as we keep them disabled authors will produce more
and more of these warnings.
But the other side is that proper fixing would probably require modifying
hundreds of OSG headers. I doubt that there is anyone brave enough to accept
this time consuming task and I doubt Robert will authorize this move.
It an impasse in which we have to choose between bad and worse. The good
thing though, is that its up to you which one you consider worse ;-)
Wojtek
Hi Paul,
Wojtek's change only restores the OSG to how it's been compiling since
the very early days w.r.t disabling the least usefu/most distractingl
of the MSVC warnings.
You can disable this via CMake, so that the OSG doesn't suppress any
warnings.
Fixing warnings is desirable, but has to be done with care as doing so
can introduce bugs - this has happened to the OSG in the past.
Warnings do often bring up ambiguities in the code that the author
didn't spot - which is good, but they also produce false positives -
highlighting code that is absolutely correct for it's intended usage,
but confuses developer into thinking that something is wrong and
fixing something that isn't broken, or just obfuscates the real
warnings amoungst the sea of false positives. For this reason I'm
cautious about diving in and doing a warnings purge.
Robert.
On Mon, Nov 24, 2008 at 9:37 PM, Paul Martz <[EMAIL PROTECTED]>
wrote:
Hi all -- Sorry I'm coming into this a little late.
What I'd really like is a clean compile so that if I introduce some
suspicious code, I clearly see a new warning message displayed in the
output, so that I can investigate it. What I don't want is to have all
warnings disabled so that I never see a message about my bogus change. If
the warning is displayed, but I miss it because it's buried in hundreds
or
thousands of other warnings unrelated to my code change, then that's just
as
bad as having it disabled and not displayed at all.
Perhaps the middle ground is to place the #pagma's in the
CMake generated include/osg/Config file?
This seems like the worst solution, because not only does it disable all
warnings in the OSG headers, it also disables it in my own application
code
that directly or indirectly includes osg/Config. If I change code and
introduce a warning, I'll never see the warning message displayed because
osg/Config disabled it.
The other approach is to do an explicit casts to avoid the
warnings in the first place. This is more wordy and while of
dubious practical value would at least fix the warnings.
Yes, this is probably the best solution, but is a prohibitive task to
bite
off for a large existing code base.
A third solution, as Wojtek mentioned, is to wrap each OSG header file
with
#pragma push/pop so that warnings can be disabled just in the header, and
not in user code that includes the header. This could be done by changing
all OSG headers to include CMake-generated prefix and suffix files that
contain the push/pops and disables. This is still an undesirable solution
because it turns all warnings off in OSG headers, even for future code
changes, but is no worse than what we had before and is relatively easy
to
implement.
-Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
