Hi Robert, I'm sorry to come late in the discussion, but I did not understand why you say the "assignment within conditional expression" warning (C4706 under MSVC) is useless. I know it is correct C/C++ to write "if (a=b)", but haven't you ever typed "a=b" instead if "a==b" in a "if" statement? It happens often to me... :) In all my projects, I set this warning to be an error so that it doesn't compile. But I understand (and agree) that putting "!=0" everywhere could be a pain for those who aren't used to.
Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 08 Jan 2009 11:40:54 +0100, Robert Osfield <robert.osfi...@gmail.com> a écrit: > Hi All, > > On Thu, Jan 8, 2009 at 9:57 AM, Robert Osfield <robert.osfi...@gmail.com> > wrote: >> My current feeling is that we should try to suppress this and a few of >> the other misleading warnings via compile options rather that >> #pragma's in the headers. So if we have /W4 on then we should then >> disable the warnings that aren't helpful. > > I've looked into the possibility and it looks like the /wd# command > line option will disable the a specific warning. So I've now > implemeneted and checked int the following: > > SET(OSG_AGGRESSIVE_WARNING_FLAGS "/W4 /wd4706 /wd4127") > > Which should disable two warnings: > > warning C4706: assignment within conditional expression > warning C4127: conditional expression is constant > > As neither of these are helpful - all the instances of code I've > reviewed that produces the above warnings looked correct, and fixing > the instances would break code cleanness/maintainability. > > Another one of dubious value looks to be: > > warning C4100: unreferenced formal parameter > > But I haven't gone for suppressing this yet as fixing the instances of > this warning wouldn't lead to any code maintenance problems. > >> We should also work towards removing the #pragma's from the headers >> completely, and work to ensure that the headers compile cleanly >> without warnings, so that 3rd party apps can go enabling/disabling >> warnings as their developers see fit. > > I have now removed the disable of C4706 from include/osg/Export but > the follow are still enabled: > > #if defined(_MSC_VER) && defined(OSG_DISABLE_MSVC_WARNINGS) > #pragma warning( disable : 4244 ) > #pragma warning( disable : 4251 ) > #pragma warning( disable : 4267 ) > #pragma warning( disable : 4275 ) > #pragma warning( disable : 4290 ) > #pragma warning( disable : 4786 ) > #pragma warning( disable : 4305 ) > #pragma warning( disable : 4996 ) > #endif > > The OSG_DISABLE_MSVC_WARNINGS define comes in from the CMake build > system which currently sets this on my default, so for testing we > could simply set this off by default and then see what warnings we > have, then we can consider on merits of providing code workarounds for > them vs suppressing them in the header or via CMake. > > As mentioned before my preference would be to fix all the warning in > the headers without any warning suppression, so that 3rd party apps > don't get polluted by warnings or suppression of warnings from the > OSG, but for the OSG source code build itself to disable the inhelpful > warnings rather than workaround them. > > The next step now would be to do some more testing w.r.t warnings > under VS to see how svn/trunk is doing, with and without > OSG_DISABLE_MSVC_WARNINGS enabled, and with > OSG_USE_AGGRESSIVE_WARNINGS enabled (as it is by default now). I > don't have access to a Windows machine so I'll need others to do a > clean build with the above settings and then post the resulting > warnings. > > Thanks, > Robert. > _______________________________________________ > 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
