It's not exactly what you asked so forgive a potentially off-topic reply. 

We recently bit the bullet and bought a copy of PC-Lint, which covers pretty much every warning i think i've ever seen under both compilers.  It took about 2 hours to set up and another 2 hours to clean up our code so it would shut up :)

We're ratcheting it up pretty tightly.  We have it set to fire about 80 of the less pedantic warnings, and it's caught an embarrassing number of "out-of-order initialization", "variable could be const", "function could be const", "don't call virtual methods from base class ctors" (we were doing it safely but still, blushing!), etc...  All in all, nothing blatantly evil (slicing, 'if (x = y)', forgetting members in copy ctors, that kind of stuff), but we sleep better at night with it there.  I'm assuming that's the kind of stuff you're aiming to capture by having warning parity across multiple compilers, yes?

It's not the fastest thing in the world.  For our unmanaged engine and game C++ code, it takes about 15 seconds to run, so we don't have the server do it on every checkin.  Instead we have the server run a lint every hour and fails a CruiseControl.NET project if lint squeaks.

Setting it up is also a pain in the ass.  The syntax is less than friendly and we got thousands of 'errors' that weren't really a big deal for us.  We ended up turning them all off and selectively re-enabling 80 or so of the more important ones, and we're not doing any of the more intrusive stuff like marking header files as belonging to libraries for deeper analysis.  If anyone wants a copy to save themselves the legwork or take a good starting point, i'd be happy to share our options.lnt file, hit me off-list.

Despite it being relatively slow and kind of painful to work with, it's been much better with than without for us, and we had previously always built our C++ at warning level 4 in vs2005.  We're not on gcc (or our final target hardware) just yet, but I really don't know how much more gcc could possibly offer in terms of warnings that PC-Lint doesn't cover already.  Other than strict aliasing warnings, that is.

Otherwise, I'd simply recommend compiling at the highest warning levels available to your compiler!  And don't turn on pedantic unless you're a masochist :)

-charles

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Ideally I'd love all the developers to not check in any code without warnings, but not everyone is compiling each platform every check in.  So their compile is warning/error free for them, but the other platform complains about something.  It would be nice to get most of the warnings that come from GCC -Wall and have them represented in VS (currently with Warning level 3, but adding warnings to get in parity with GCC).

It is useful to get a variety of warnings, it would be nice if there was more overlap in this warnings for each platform.  I don't want to remove any warnings, just get some of the same on each platform/config.  The purpose of doing this would be to reduce the number of build breaks and the time it takes for the fix for breaking the build to come in.

Ralph

Bryan Wagstaff wrote:

Does anyone know of a resource or the list of Visual Studios warnings that encompass the gcc -Wall warnings?

They do not directly map to each other. With the exception of the blatant language violations, most warnings are different between compilers. Although there is a lot of overlap, there are many things caught by one compiler that are undiagnosed with the other. We have found that this is useful behavior. We use three different compilers, one per platform. All the compilers are turned on to the highest warning level with warnings treated as errors, and the code must compile and run on all platforms before being submitted to the main branch. It is often the case among junior developers that they will write code that compiles cleanly on one platform (usually VC++) that fails to compile on another platform. Almost always this is due to a bug in their code. Of course, tenured programmers like me NEVER have that problem.

I've got a multiplatform project and I'd like the warnings to be the same (same type of warning) for each build configuration.

I'm curious why you think that this mapping would be useful to your project. Hopefully your developers would fix any warnings before submitting it, so I can't imagine it being too useful for automated build scripts or similar tools. When a developer breaks the build it is easy to track it back to the checkin that broke it. What do you hope to gain by getting all your warnings to be similar among each configuration? _______________________________________________ Sweng-Gamedev mailing list Sweng-Gamedev <at> lists.midnightryder.com http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

On a similar note I just installed the Windows Vista SDK, which comes with a MS compiler that has a static code analyizer (/analyze).  We were thinking about PC-Lint, but thought it would be nice to see what the MS Compiler did.  The VS Team edition already has this option I believe.  If you have a PC project you can run it against that, and you can also run it against the Xbox version (it won't compile, but you can just look at the analysis warnings (certain range)). 

Just install the SDK, and in VS -> Tools -> Options -> Projects and Solutions -> C++ Directories -> Executable files > put the bin directory for the new cl.exe first.  Pass in additional parameters of /analyze for your project.  It was pretty easy, and found a decent number of errors.

It isn't hooked up to the build system, but I figure running that every now and then and fixing what crops up is acceptable.

Ralph

Charles Nicholson wrote:

It's not exactly what you asked so forgive a potentially off-topic reply. 

We recently bit the bullet and bought a copy of PC-Lint, which covers pretty much every warning i think i've ever seen under both compilers.  It took about 2 hours to set up and another 2 hours to clean up our code so it would shut up :)

We're ratcheting it up pretty tightly.  We have it set to fire about 80 of the less pedantic warnings, and it's caught an embarrassing number of "out-of-order initialization", "variable could be const", "function could be const", "don't call virtual methods from base class ctors" (we were doing it safely but still, blushing!), etc...  All in all, nothing blatantly evil (slicing, 'if (x = y)', forgetting members in copy ctors, that kind of stuff), but we sleep better at night with it there.  I'm assuming that's the kind of stuff you're aiming to capture by having warning parity across multiple compilers, yes?

It's not the fastest thing in the world.  For our unmanaged engine and game C++ code, it takes about 15 seconds to run, so we don't have the server do it on every checkin.  Instead we have the server run a lint every hour and fails a CruiseControl.NET project if lint squeaks.

Setting it up is also a pain in the ass.  The syntax is less than friendly and we got thousands of 'errors' that weren't really a big deal for us.  We ended up turning them all off and selectively re-enabling 80 or so of the more important ones, and we're not doing any of the more intrusive stuff like marking header files as belonging to libraries for deeper analysis.  If anyone wants a copy to save themselves the legwork or take a good starting point, i'd be happy to share our options.lnt file, hit me off-list.

Despite it being relatively slow and kind of painful to work with, it's been much better with than without for us, and we had previously always built our C++ at warning level 4 in vs2005.  We're not on gcc (or our final target hardware) just yet, but I really don't know how much more gcc could possibly offer in terms of warnings that PC-Lint doesn't cover already.  Other than strict aliasing warnings, that is.

Otherwise, I'd simply recommend compiling at the highest warning levels available to your compiler!  And don't turn on pedantic unless you're a masochist :)

-charles

On 10/15/07, Ralph <spam0rz <at> gmail.com> wrote:

Does anyone know of a resource or the list of Visual Studios warnings
that encompass the gcc -Wall warnings?  I've searched the google and
could've get anything useful.  I've got a multiplatform project and I'd
like the warnings to be the same (same type of warning) for each build
configuration.  Any hints or pointers would be welcome.

Ralph
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

_______________________________________________ Sweng-Gamedev mailing list Sweng-Gamedev <at> lists.midnightryder.com http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Well, the project started out with VS on W3 and GCC on Wall, so I'm just tried to get some parity between them.  They are mostly the same except for a few warnings that pop up on GCC and not VS.  I've tried going to W4, but at this point we spew lots of warnings, and I haven't felt the desire to tackle that yet.  I've been marching on a process of reducing the number of warnings that are tolerated in the build.  We just recently went to warnings as errors.  And we generally have none to few.  We don't have a check in policy that says the programmers have to build for all platforms, and I think we can get away with that.  We have a build machine that builds every platform and every config after checkins (I assume most here do this).  If this breaks, or generates warnings to the people who checked in get mail.

My ultimate goal is to keep the GCC version less broken, and to do that, the easiest way is to enable those warnings we only get in GCC in VS.  The others require team changes or behavior changes at this point, which I'd rather avoid.  ;)

Ralph


Jim Tilander wrote:

Ralph, Is there a reason why you don't enable warning level 4 on MSVC? That coupled with disabling some of the warnings on gcc would probably get you somewhere towards where you want to be in terms of overlapping warnings. Now, I wouldn't recommend doing that though, I'd just enable all the warnings I could find and leave them on both compilers. There are very few select warnings that I would disable, but other than that I think that every warning the compiler bothers to issue, you should inspect and ponder for a while. The more the better. Another problem seems to be the issue why not everyone on your team feels that they can compile on all the platforms before checking in? It sounds to me that they should start compiling at least on the compiler that issues the most warnings first and maybe skip in a pinch the compiler that has the weakest warnings (usually MSVC). I've worked on a small team where we had the policy that if it ran on one platform you were ok to check in, but anyone that found any warnings / breakages had to fix them. It worked great because we were a small team and everybody took responsibility but if any of those lack, then you have a problem. Most likely you will wind up with one platform (high chance of that being the non win32 one) being constantly broken by code that simply doesn't work / spams warnings all over the place. At that point you got to ask yourself if this is acceptable behavior for a group of people to check in constantly broken code (code that issues warnings is in my eyes broken). Maybe it is. You could assign one person to monitor the situation and fix the warnings as they come in. However that person will probably go nuts after a while if you have a decent sized team... As for fixing the build once it's broken, it should be fairly simple with most warnings. If there simply are too many, hey -- source control is there to be used. Reverting a changelist in perforce can be done in a matter of seconds (you can even use a script to do it http://www.tilander.org/aurora/articles/000028.html). Then people can continue working and you can fix the warnings without stress. /j p.s. (as it happened I just had to rant a little about warnings yesterday http://www.tilander.org/aurora/articles/000036.html). On 10/15/07, Ralph <spam0rz <at> gmail.com> wrote:

Ideally I'd love all the developers to not check in any code without warnings, but not everyone is compiling each platform every check in. So their compile is warning/error free for them, but the other platform complains about something. It would be nice to get most of the warnings that come from GCC -Wall and have them represented in VS (currently with Warning level 3, but adding warnings to get in parity with GCC). It is useful to get a variety of warnings, it would be nice if there was more overlap in this warnings for each platform. I don't want to remove any warnings, just get some of the same on each platform/config. The purpose of doing this would be to reduce the number of build breaks and the time it takes for the fix for breaking the build to come in. Ralph Bryan Wagstaff wrote: Does anyone know of a resource or the list of Visual Studios warnings that encompass the gcc -Wall warnings? They do not directly map to each other. With the exception of the blatant language violations, most warnings are different between compilers. Although there is a lot of overlap, there are many things caught by one compiler that are undiagnosed with the other. We have found that this is useful behavior. We use three different compilers, one per platform. All the compilers are turned on to the highest warning level with warnings treated as errors, and the code must compile and run on all platforms before being submitted to the main branch. It is often the case among junior developers that they will write code that compiles cleanly on one platform (usually VC++) that fails to compile on another platform. Almost always this is due to a bug in their code. Of course, tenured programmers like me NEVER have that problem. I've got a multiplatform project and I'd like the warnings to be the same (same type of warning) for each build configuration. I'm curious why you think that this mapping would be useful to your project. Hopefully your developers would fix any warnings before submitting it, so I can't imagine it being too useful for automated build scripts or similar tools. When a developer breaks the build it is easy to track it back to the checkin that broke it. What do you hope to gain by getting all your warnings to be similar among each configuration? _______________________________________________ Sweng-Gamedev mailing list Sweng-Gamedev <at> lists.midnightryder.com http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com _______________________________________________ Sweng-Gamedev mailing list Sweng-Gamedev <at> lists.midnightryder.com http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Change the linker options to omit /opt:ref ?

_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com