$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [warnings] Are warnings acceptable artifactsfrom builds?
From: Kenny Riddile (kfriddile_at_[hidden])
Date: 2009-09-08 17:10:57
Emil Dotchevski wrote:
> On Tue, Sep 8, 2009 at 1:44 PM, Kenny Riddile<kfriddile_at_[hidden]> wrote:
>> Emil Dotchevski wrote:
>>>> I think that warnings must be fixed when the needed work is not huge. It
>>>> will be great if Boost defined which warning must be fixed and which ones
>>>> are allowed. When a warning is allowed and not fixed a comment on the line
>>>> could help users to know if the warning is know (will not be fixed) or if
>>>> it is a new one. In this way the author will compare the effort to fix it or
>>>> add the comment.
>>> I disagree. Warnings are a personal conversation between the compiler
>>> and the author of the code. They are nobody else's business.
>>>
>> That statement seems to conflict with your argument against fixing/silencing
>> warnings in library code. For example, I am not the author of
>> Boost.Exception, therefore any warnings emitted by it are none of my
>> business. According to what you just said, the only person who should ever
>> see warnings emitted by Boost.Exception is you.
>
> Yes, so don't look at any warnings in Boost.Exception :P
>
> Emil Dotchevski
> Reverge Studios, Inc.
> http://www.revergestudios.com/reblog/index.php?n=ReCode
> _______________________________________________
> Unsubscribe & other changes: http://listarchives.boost.org/mailman/listinfo.cgi/boost
>
If that was an option, I would certainly follow that advice :)
Unfortunately, when sifting through warnings emitted by code of which I
AM the author, warnings from library code will inevitably scroll across
my screen, be projected onto my retinas, and become my "business"
whether I like it or not. Then there's also the fairly common case of
warnings-as-errors/highest-warning-level which needs no explanation.
What you're suggesting simply isn't possible. A fair alternative would
be to have a list of acceptable warnings (assignment operator could not
be generated, etc.), and mandate that no other warnings be emitted by
Boost libraries on supported compilers.