Re: [boost] [new Warnings policy] MS C4180 ontheMaintenance Guidelines

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.

Patrick