Subject: Re: [boost] Towards a Warning free code policy proposal
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-08-30 12:51:57
On 30.08.2010 15:12, Stewart, Robert wrote:
> Artyom wrote:
>> IMHO: let library developer decide what to disable and what policy
>> he should use. Developer that respects himself would code the way
>> the code compiles with severe warning level.
> Boost is thought of as a whole made of parts. If the parts differ
> wildly in how things are addressed, the whole suffers. That's why we
> have high documentation standards for all Boost libraries, for
> example. Consequently, without some minimum standard for warnings,
> there may be too much variation.
> There should be guidelines on things to avoid when trying to fix
> warnings. Emil's favorite is to avoid casts because they bypass the
> implicit type conversion system in the language and can hide
> problems. I don't agree entirely with his concerns, but there is
> value in what he says.
> We need guidelines that prescribe and others that proscribe to ensure
> best practice.
I think, you both are right here.
Maximum level warnings are simply not practical, at least with compilers
I dealt with. I honestly don't understand those who think that
warning-free code is somehow more solid than the code which emits
warnings. Writing code that emits no warnings on all compilers Boost
supports is a nightmare and I would even say that the quality of such
code would be worse in some respect. Adding casts, pragmas, removing
parameter names and adding conditional compilation to avoid "unsafe"
functions - all this makes the code more complicated and harder to
maintain and understand. I don't like warnings and I'm for fixing them -
but only up to the point when it doesn't hurt the code clarity. This
usually amounts up to /W3 on MSVC and default warning settings on GCC.
Some warnings, like signed/unsigned comparison and uninitialized
variables, often indicate real bugs and should be taken care of. I'd
suggest to make a list of such warnings (or warning settings on
particular compilers) and try to avoid them in Boost. Note that I'm
against making this list of all warnings at the highest levels and as
such I'm not offering a solution for those seeking for a warning-free
Boost. I think, the list will be quite short, in fact. But by following
this guideline we will improve Boost code quality without paying much
time and nerves. I think, Paul's Wiki page is a good starting point in
On the original topic:
* I don't think that adding the ability to mask out all Boost warnings
is of much use. After all, if users are trying to make their code
warning-free, they probably want to make the code more safe and
bug-free. Hiding warnings in libraries they use (Boost included) looks
like a disservice, since the warnings may be valid.
* If a user encounters valid warnings with Boost, he should be
encouraged to report them back so that we could fix them in Boost code.
In case if the warning is spurious and the developer doesn't want to
cripple the code to work it around, the user is usually able to mask it
away for Boost locally (by pragmas or by warning settings on his
particular compiler; on GCC one could even use -isystem).
That's why I don't think that adding the policy is a good idea for Boost
in general. However, particular library developers may offer this
feature of their own libraries, on their free will.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk