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.
> Unsubscribe & other changes: http://lists.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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk