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

Reply via email to