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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to