Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-11-05 17:55:20

AMDG

Patrick Horgan wrote:
> 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.

I didn't say that it wouldn't.

> 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.

IMHO, the value of suppressing warnings on one compiler is
relatively high.  When using more compilers, the amount of
noise tends to increase more than the number of new problems
found.

> 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.

I might point out that the ones that we're always arguing about are the 
silly ones.

> 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.

The compiler is not always right in what it thinks you should do.
It's the library authors call how to deal with an issue as long as
the solution is correct.  Boost often uses techniques
that do not fit in traditional OO models which is what this warning
is designed for.

In Christ,
Steven Watanabe