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

Subject: Re: [boost] Towards a Warning free code policy proposal
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-08-28 07:34:56

----- Original Message ----- 
From: "John Maddock" <boost.regex_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, August 28, 2010 11:26 AM
Subject: Re: [boost] Towards a Warning free code policy proposal

> 
>>Last year there where two long threads about Boost Warning policy. If I'm 
>>not wrong nothing was concluded.
>>I think that we can have two warning policies: one respect to the Boost 
>>users and one internal for Boost developement.
> 
> There was some progress towards fixing warnings:
> 
> https://svn.boost.org/trac/boost/wiki/WarningFixes
> 
> Also I'm fairly sure that Paul Bristow started a "How to fix warnings" 
> guidelines page, but I can't find it right now :-(

I can see it now that the wiki has been recovered.
 
>>We can consider that Boost headers can be used by the users as system 
>>headers, so no warning is
>>reported for these files. The main advantage I see is that it allows the 
>>users to don't mix the
>>warnings comming from Boost and their own warnings.
> 
>>Next follows a way to disable completly warnings for 3 compilers: Any Boost 
>>header file could be surrounded by
> 
> 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. 
"
> 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.

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

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

> 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?

Best,
Vicente