Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at