Re: [boost] Official warnings policy?

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
     "failures"?
     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
   low-hanging fruit.
   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!
   Patrick