Subject: Re: [boost] Official warnings policy?
From: Patrick Horgan (phorgan1_at_[hidden])
Date: 2009-11-04 16:06:20
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.
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
software. In my code, I get rid of all the warnings from compiling at high
warning levels. Currently, for one project, I'm using (for gcc) -ansi
-pedantic -Wextra -Wwrite-strings -Wformat=2 -Wall. I use a lot of
templated code and have a clean compile. Not a single warning. When I
started doing that years ago, the quality of my code immediately increased
and has stayed much higher ever since.
An example of one of my least favorite avoidable warnings is when one part
of boost moves an include file and deprecates the old location, and release
after release, I have to look at warnings from other parts of boost. I
can't even say what I think about that. I don't think a release should go
out with issues like that. Boost should at least be internally consistent,
and not have warnings about misusing other parts of boost. You'd think that
would be the bare minimum to avoid looking like amateurs. How hard would it
have been to fix for example, in 1.40 when I see hundreds of warnings from
the graph stuff because:
boost/property_map.hpp:15:4: warning: #warning "This header is deprecated.
Please use: boost/property_map/property_map.hpp"
I'm guessing the graph guys are used to ignoring warnings. But the code was
released like this. That's embarrassing. There's probably 35 places they
would have had to fix this so that hundreds of errors wouldn't spew out
whenever someone used their code. They aren't even willing to grab the
There have long been other places where boost code used deprecated headers
from the standard libraries. That's unprofessional.
Sorry to rant. This is a long standing issue for me and I thought I better
write this before I saw the inevitable responses from people trying to
justify their bad coding. I really would have ranted then!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk