Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Patrick Horgan (phorgan1_at_[hidden])
Date: 2009-11-05 16:50:05

Steven Watanabe wrote:
> The point is not that fixing warnings would not make Boost better.
> I'm saying that if the correctness of Boost were the only consideration,
> the effort spent dealing with warnings could probably be better spent
> in other ways (Such as dealing with the >850 open trac tickets).
> The main problem with warnings is not that they indicate bugs, so
> much as that they make the code less usable because of the noise
> that they generate for users.
Au Contraire!  Fixing warnings can quite likely make code better.  
Whenever I've been involved in a project that generated lots of warnings 
and the effort was made (often at my encouragement), to clean them up, 
people found real bugs--things that embarrassed them.  They had been 
told by the compiler about them, but because of the noise, missed the 
information.  I certainly include myself in that.  Those embarrassments 
are why I go with a policy of cleaning up all the warnings.  I don't 
like being surprised by bugs I ignored, and it's especially bad if 
someone else finds it first.  You quickly learn to code differently and 
don't generate more warnings.

I notice that much of the discussion from people who don't want to fix 
warnings has focused on the silly ones.   They seem to have been trained 
by compiler writers to ignore warnings.  That's frustrating.  Getting 
rid of your warnings is a good coding practice, and if all of them are 
the silly ones you're a better coder than I.  If you have virtual 
functions and no virtual destructor, and you know why, for example, it 
can be frustrating to get whined at.  But, if you provide the virtual 
destructor, you make it so that someone else maintaining your code years 
down the road won't be able to easily screw the pooch.

Patrick