Re: [boost] Supressing warnings

From: Oliver Kullmann (O.Kullmann_at_[hidden])
Date: 2006-06-27 08:28:39

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