Re: [boost] Towards a Warning free code policy proposal

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 
this direction.

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.