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 05:26:24

>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 :-(

>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.
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. 
Unfortunately, not all have been fixed: for example 
https://svn.boost.org/trac/boost/ticket/3606
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*.
4) Blanket disabling does nothing for compilers that don't have such 
mechanisms - indeed I would contend that it would make things worse, as the 
trend would be towards "don't worry about warnings".
5) I worry that this would lead towards poorer quality code and an "out of 
sight out of mind" mentality.
6) As a last resort, we can always resort to - preferably selective - 
disabling methods when all else fails.

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!

Anyhow, I'll jump down off my soap box now ;-)

John