Re: [boost] Towards a Warning free code policy proposal

Subject: Re: [boost] Towards a Warning free code policy proposal
From: John Maddock (boost.regex_at_[hidden])
Date: 2010-08-28 12:14:25

>> I'm completely against disabling warnings in such a blanket manner for a
>> number of reasons:
>>
>> 1) It doesn't fix anything, it hides it.
>
> I would say, it enables users to hide Boost warnings. If you prefer 
> instead on setting the defaul as warnings disabled, we can enable them as 
> default, and let the user disable them with just one define.
>
>> 2) I have found legitimate bugs in both my code and others as a result of
>> fixing what looked to be "busy-body" warnings at first glance.
> As I said in the initial post: "Of course this policy don't mean that the 
> developer should not take care of the warnings.
> "

Sure, but the incentive to do so is removed.

>> 3) As others have noted, some warnings are only emitted when a template 
>> is
>> instantiated with certain template arguments - in this case the warning 
>> may
>> be telling the user something important about the template arguments that
>> they're using and *should be seen*.
>
> The user can always define BOOST_ENABLE_WARNINGS, so warnings will be no 
> suppresed using this technique.

I don't believe a casual user will realise that such a thing is needed or 
available - boost is complex enough to get to grips with already.

>> 4) Blanket disabling does nothing for compilers that don't have such
>> mechanisms -
>
> Well there are 3 main compiler family that allow it. I don't know for 
> others.
>
>> indeed I would contend that it would make things worse, as the
>> trend would be towards "don't worry about warnings".
>
> I don't agree. If regressions are runned with BOOST_ENABLE_WARNINGS and if 
> as other sugested we have some compilers with warning-as-error set, this 
> could be the bases of a clear warning free strategy.
>
>> 5) I worry that this would lead towards poorer quality code and an "out 
>> of
>> sight out of mind" mentality.
>
> I repeat. I'm not purposing to don't fix the warnings. Just to give the 
> user the posibility to supress all the Boost warnings.

I understand that, I'm just saying that human nature being what it is, the 
chances of any warnings actually getting fixed if they've been explicitly 
disable is close to zero IMO.

>> 6) As a last resort, we can always resort to - preferably selective -
>> disabling methods when all else fails.
>
> I agree, we need to eliminate the warnings and suppress them when all else 
> fails in the most localized way.
> The problem is that currently there are a lot of warnings that are not 
> hadled. The strategy I'm porposing just helps to achieve 0 warnings (for 
> some compilers :) for users that needs this warning free code as a 
> preamble to install Boost on his project.

Maybe.  The interesting thing is, I don't believe we're that far from zero 
warnings for most libraries anyway, it just requires someone to care enough 
to fix them (usually not hard IMO), and for the maintainer to care enough to 
apply the patches.

>> So... yes we need to do something about warnings, and yes I would like to
>> see our tests run with "warnings as errors" for some compilers at least, 
>> but
>> please not like this!
>
> Could some of the testers set up a configuration with warnings as errors 
> set?

That would certainly focus minds :-)

John.