Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-11-07 10:28:33

AMDG

Patrick Horgan wrote:
>    Herb Sutter and Andrei Alexandrescu (who is following this discussion on
>    boost) were kind enough to give me permission to quote their item 1 from C++
>    Coding Standards (note that I screen scraped this from [1]www.artima.com who
>    also had their permission to post)  You might consider buying a copy, it's a
>    wonderful book;) :
>   

Indeed.  I've read it.

>                   1. Compile cleanly at high warning levels.
>
> Summary
>
>    Take warnings to heart: Use your compiler's highest warning level. Require
>    clean (warning-free) builds. Understand all warnings. Eliminate warnings by
>    changing your code, not by reducing the warning level.
>
> Discussion
>
>    Your  compiler  is  your  friend. If it issues a warning for a certain
>    construct, often there's a potential problem in your code.
>
>    Successful builds should be silent (warning-free). If they aren't, you'll
>    quickly get into the habit of skimming the output, and you will miss real
>    problems. (See Item 2.)
>
>    To get rid of a warning: a) understand it; and then b) rephrase your code to
>    eliminate the warning and make it clearer to both humans and compilers that
>    the code does what you intended.
>
>    Do this even when the program seemed to run correctly in the first place. Do
>    this even when you are positive that the warning is benign. Even benign
>    warnings can obscure later warnings pointing to real dangers.
>
> Examples
>
>    Example 1: A third-party header file. A library header file that you cannot
>    change could contain a construct that causes (probably benign) warnings.
>    Then wrap the file with your own version that #includes the original header
>    and selectively turns off the noisy warnings for that scope only, and then
>    #include your wrapper throughout the rest of your project. Example (note
>    that the warning control syntax will vary from compiler to compiler):
> // File: myproj/my_lambda.h -- wraps Boost's lambda.hpp
> //   Always include this file; don't use lambda.hpp directly.
> //   NOTE: Our build now automatically checks "grep lambda.hpp <srcfile>".
> // Boost.Lambda produces noisy compiler warnings that we know are innocuous.
> // When they fix it we'll remove the pragmas below, but this header will still
> exist.
> //
> #pragma warning(push)   // disable for this header only
>   #pragma warning(disable:4512)
>   #pragma warning(disable:4180)
>   #include <boost/lambda/lambda.hpp>
> #pragma warning(pop)    // restore original warning level
>   

This works great for suppressing warnings on msvc, but gcc says:

test.cpp:1: warning: ignoring #pragma warning
test.cpp:2: warning: ignoring #pragma warning
test.cpp:3: warning: ignoring #pragma warning
test.cpp:5: warning: ignoring #pragma warning

> <snip>
>
> Exceptions
>
>    Sometimes, a compiler may emit a tedious or even spurious warning (i.e., one
>    that  is  mere noise) but offer no way to turn it off, and it might be
>    infeasible or unproductive busywork to rephrase the code to silence the
>    warning. In these rare cases, as a team decision, avoid tediously working
>    around a warning that is merely tedious: Disable that specific warning only,
>    disable it as locally as possible, and write a clear comment documenting why
>    it was necessary.
>   

IMHO, this really underestimates the number of spurious
warnings that compilers are liable to generate if given
half a chance.

The issues for a library like Boost are somewhat different
from what an application needs to deal with.  First of all,
warnings in headers don't just affect us, they affect all users
of the library.  In addition, we have no control over what
warnings are enabled.  We have to be able to deal with
whatever users throw at us.  Further, Boost has to run on
many different compilers.  Compiling with zero warnings
on all compilers is simply infeasible.  If we just wanted to
make sure that silly errors are caught, it would be much
more effective for each library developer to pick his favorite
compiler and make sure that his code compiles cleanly
with a reasonable warning level.  Note that "reasonable"
does not mean all possible warnings (Sutter and Alexandrescu
not withstanding).  There are some warnings that are always
noise or are nonsense in the context of Boost.  MSVC's
C4512, tends to generate a large amount of noise and has
only helped my find a bug once (I don't give much credit to
it for this.  I already knew the bug existed.  It only helped
because it happened to generate a template instantiation
backtrace at exactly the right point).  Another example
is warnings that are designed for a specific programming
paradigm.  -Weffc++ is not appropriate with Boost, and
the warnings that it generates can be impossible for us to
suppress because they can occur in user code.

In Christ,
Steven Watanabe