In my opinion, a major problem with paying attention to warnings and changing the code in order to prevent warnings is, that in this way the code is not only written for a *special compiler*, but even **for a special compiler version**. I don't think that this is good practice. More and more people realise, that the code "should speak the truth", but code can be obfuscated by trying to prevent compiler warnings (for some special compiler, in some special version). Below I discuss some examples, where code is impaired by "preventing warnings". Having said this, in my experience gcc, version 4.1 or later, with "-ansi -pedantic -Wall" works quite well.
NOTE: Instead of disabling the warnings, you can remove the warning by updating the code. For example:
void foo( int bar ){} // unreferenced parameter void foo( int bar ){ bar; } // no warning!
this is FALSE: void foo(int){} is the right solution here, and follows the language. In "void foo( int bar ){ bar; }" only the special properties of build-in types makes it sementically equivalent, not so for other types; codes can get cluttered with these meaningless "helpful suggestions", less understood by the maintenance programmer, and when the type "int" gets upgraded to "Int" (big integers for example) then already something might happen (and other more extreme cases are conceivable).
bool foo(){ BOOL bar = TRUE; return bar; } // performance warning bool foo(){ BOOL bar = TRUE; return bar != FALSE; } // no warning
this is a perversion.
class foo { bar & m_bar; foo( bar & b ): m_bar( b ){}
// disable the no default compiler assignment operator warning: inline foo & operator=( const foo & ); };
again this is a perversion: the C++ should follow the LANGUAGE, and the special handling of the *special member function* is important part of C++. In the above example, first "inline" shouldn't be there, and then it's not about warnings, but about semantics: either we want the implicitely declared copy assignment operator, and then we *must not* add that line, or we don't want it, and then we *must* add the line --- there is no choice. Oliver