Subject: Re: [boost] [new Warnings policy] MS C4180 on the Maintenance Guidelines
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-11-20 15:50:44
On Fri, Nov 20, 2009 at 6:33 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Emil Dotchevski wrote:
>> On Thu, Nov 19, 2009 at 5:24 AM, Stewart, Robert
>> <Robert.Stewart_at_[hidden]> wrote:
>> > Emil Dotchevski wrote:
>> >> I propose to replace all of the existing
>> >> warnings guidelines in the Wiki with the following: "No warnings
>> >> should be emitted by Boost code. Use your best judgment to
>> >> either fix or suppress the warning."
>> > I like the simplicity of this statement of purpose, but
>> > there's value in
>> > educating developers on how to judge whether to fix or suppress a
>> > warning and in the information on how to deal with specific warnings
>> > and compiler vagaries.
>> If I understand correctly, you are concerned with the possibility of
>> developers suppressing warnings as opposed to "fixing them properly."
>> My wording, which is indeed intended to be complete, specifically
>> seeks to avoid such differentiation. Rather than arguing what is right
>> and what is wrong, we should consider the simple fact that if a Boost
>> developer suppresses a warning in a particular library, there are no
>> reasonable grounds to require the warning to be enabled and the code
> You seem to make two assumptions: warnings are nuisances that
> should be ignored and all Boost authors and maintainers have sufficient
> knowledge to judge whether a warning should be ignored (suppressed).
I don't think I made any of these assumptions. My assumptions are:
1) Boost developers have enough knowledge of C++ programming to
understand what a warning says.
2) Boost developers, knowing what the warning says, and having
designed the code in question, are best equipped to decide what action
should be taken.
Obviously, if a warning indicates a bug, the *bug* has to be fixed,
but that's just common sense, we don't need a policy for this case.
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk