Subject: Re: [boost] [new Warnings policy] MS C4180 ontheMaintenance Guidelines
From: Patrick Horgan (phorgan1_at_[hidden])
Date: 2009-11-20 14:05:29
Peter Dimov wrote:
>> Warnings often indicate real problems.
> In this case, the real problem should be fixed - no matter whether it
> causes a warning or not on compilers we care about. We already know
> how to do this. There is no need to have a "warning policy" to fix
> bugs (I hope!)
> A "warning policy" is only needed for warnings that do not indicate
> real problems.
Something that is sometime lost here, is that just because a particular
warning, about a particular line of code, doesn't indicate a bug, i.e.
incorrect behavior, that doesn't imply that it's not a problem. (Wow,
that's really bad English, but it's ok, I speak Texan most natively.;)
Fixing warnings by doing code changes allows you to leave warnings
enabled, and that same warning, on that line or another, in the future
may very well point you right to a bug. Fixing warnings like that
sometimes even result in better code, i.e. more readable, more
maintainable, more correct, able to resist subtle bugs, but not always.
What they do result in is code that can take advantage in the future of
all the aid a compiler can give you in catching problems before they
escape out into the wild. That's the real reason for making your code
so that it can compile with high warning levels without problems. Of
course, as you work through your code and get rid of the warnings you
always find real bugs too, as some on this list have recently reported
while cleaning up their own code. That's just icing on the cake. Those
bugs would have already been found if they had already had warning clean
code and built at high warning levels. The quality of their code is now
higher, and will stay higher. Going through this process takes sloppy
code and tightens it up.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk