Boost logo

Boost :

Subject: Re: [boost] Official warnings policy?
From: Bo Persson (bop_at_[hidden])
Date: 2009-11-05 11:57:39


Emil Dotchevski wrote:
> On Wed, Nov 4, 2009 at 2:05 PM, Bo Persson <bop_at_[hidden]> wrote:
>> Emil Dotchevski wrote:
>>> On Wed, Nov 4, 2009 at 12:12 PM, Vladimir Prus
>>> <vladimir_at_[hidden]> wrote:
>>>> Emil Dotchevski wrote:
>>>>>> Unfortunately,
>>>>>> recent discussion left me with the impression that few folks
>>>>>> care.
>>>>>
>>>>> It is not about caring, once again the argument is about a
>>>>> personal preference: is the ugliness and decreased readability
>>>>> that is often required to silence a warning reasonable.
>>>>
>>>> I suggest we don't talk in the abstract. Once a specific set of
>>>> warning options, together with -Werror is in place, you can raise
>>>> your concerns
>>>> about any particular warning emitted by any particular compiler,
>>>> and hopefully, some per-warning-kind agreement can be reached.
>>>
>>> I agree that the only way warnings can be addressed effectively is
>>> to
>>> use -Werror. On the other hand, the idea that a warning is the
>>> same as
>>> an error challenges my world view. :)
>>>
>>> I understand why you say that we can't talk in the abstract. It's
>>> downright silly not to fix certain "good" warnings and we, as a
>>> community, definitely can agree on a reasonable definition of
>>> "good".
>>>
>>> However this will not address the issue at hand, which is that
>>> people
>>> who use higher warning levels will see tons of warnings. A better
>>> attitude is http://www.zlib.net/zlib_faq.html#faq35.
>>
>> Yes, that's a good attitude. However, how are we going to be sure
>> that the code works, when the compiler says it might not?
>
> How we are going to be sure that the code works is not a simple
> question, but note that "fixing" a warning simply silences the
> compiler and (ideally) has no effect on the correctness of the code:
> if the code was buggy, it still is.
>
> (Qualifying the above with "ideally" is necessary because sometimes
> fixing a lame warning on one platform could also silence a valid
> warning on another platform.)
>

I'm not arguing that the code should be obfuscated to satisfy every
compiler, but that there could be an official policy that some
warnings are really silly and disabled.

Perhaps they could be enabled by defining
_BOOST_ENABLE_SILLY_MSVC_WARNINGS? Or just document that the code
compiles cleanly if I disable the silly warnings.

Having Boost compiling at /W2, possibly aiming for /W3, is not
impressing on those who's code already compile at /W4 (with a few
really silly warnings disabled).

Note that VC10 has an additional /Wall level, higher than /W4. :-)

Bo Persson


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk