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

Subject: Re: [boost] Towards a Warning free code policy proposal
From: Bo Persson (bop_at_[hidden])
Date: 2010-08-30 13:50:19

Andrey Semashev wrote:
> 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.

This is from the library writer's perspective. What about the 
potential library user?

If I have a code base that compiles cleanly with MSVC at /W4, I really 
don't like to lower my settings to /W3 or /W2 just because the library 
should also be compilable by SunStudio or a 10 year old Borland 
compiler.

What do I care?  :-)

The curse of a portable library falls on a user who's code isn't 
portable anyway.

Bo Persson