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 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
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 undocumented. 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" http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html 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