Re: [boost] [new Warnings policy] MS C4180 on the Maintenance Guidelines

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
>> "fixed".
>
> 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.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode