Boost logo

Boost :

Subject: Re: [boost] Towards a Warning free code policy proposal
From: Bo Persson (bop_at_[hidden])
Date: 2010-08-28 05:53:57

John Maddock wrote:
> 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
> 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

I totally agree with this.

When targeting a specific compiler, a 3rd party library can use
non-standard but implementation defined behavior. You cannot use
implementation specific behavior, especially not if it is

The implementor of a specific compiler's standard library can, and
probably must, use these extensions. However, when they are "granted
on an ad-hoc basis"

it would be extremely dangerous for anyone else to rely on these
features. How do we know exactly what they are, or when they change?

Bo Persson

Boost list run by bdawes at, gregod at, cpdaniel at, john at