Subject: Re: [boost] Official warnings policy?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-11-04 20:50:34
On Wed, Nov 4, 2009 at 1:06 PM, Patrick Horgan <phorgan1_at_[hidden]> wrote:
> John Maddock wrote:
> I'm *not* saying we should do this for 1.41, but should we have an
> official policy regarding compiler warnings and which ones we regard as
> I realize these can get pretty busy-body at times, but if the user sees
> several pages of warnings when building Boost it doesn't look so good.
> It not only doesn't look good. It isn't good. As Herb Sutter and Andrei
> Alexandrescu point out in Item 1 in C++ Coding Standards which says compile
> cleanly at high warning levels, if you get used to ignoring warnings, it is
> guaranteed to bite you in the butt. I know people will talk about silly
> examples, and how hard it is. Wah wah wah. I find real errors in the code
> of people like that all the time. They got used to ignoring warnings and
> real problems got by them. Someone who isn't willing to understand the
> warnings is asking for trouble, and I know there are people in boost who
> don't take the trouble to understand their warnings. I see things that are
> silly, and that they should have fixed. I don't see how they can hold their
> heads up for some of this stuff.
It isn't helpful to cast the blame generically like that. I don't know
how you know that Boost developers don't take the trouble to
understand their warnings, but a good start would be to file a
specific bug report whenever you suspect that a warning is being
> Of course, there are silly warnings. Sometimes the problem is with the
> compiler. But still, make them go away if at all possible, otherwise the
> noise makes it difficult/impossible to catch the real problems, and all that
> noise makes you look like a rookie wanna be, not the provider of serious
Should I understand that your code compiles on MSVC without disabling
C4996? It tends to generate a lot of noise even at low warning levels.
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk