Re: [boost] Supressing warnings

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

> |  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). 
> 
> What about the MSVC warning 4127?
> 
> silenced with
> 
> #  pragma warning(disable: 4127) // conditional expression is constant.
> 
> No amount of recoding can help with this can this - a constant conditional
> expression is exactly what one was trying to achieve!
> 
> What are you suggesting for this?
> 
> Doing nothing is not an option, if you accept my premise that a -pedantic or
> MSVC level 4 compile without warnings is what we want.
> 
> What mechanism for suppressing it is best?
> 
> |  Having said this, in my experience gcc, version 4.1 or later,
> |  with "-ansi -pedantic -Wall" works quite well.
> 
> Does it produce a "conditional expression is constant" warning?
> (Or similar generally unhelpful messages).
>

I just tried out several examples with gcc 4.1.0 and 4.1.1,
using "-ansi -pedantic -Wall", and it didn't produce any warnings.

Since error messages and warnings are not standardised, steps taken
to silence one compiler(-version) might awaken another compiler(-version).
(This was also mentioned in another reply.)

Warnings should be there to help us, and not to bother us, or even dictate
(bad) style; if the warning is *meaningful*, and we actually can *improve*
the code, then fine, but otherwise the warning should be ignored

My experience with gcc and "-ansi -pedantic -Wall" is actually, that except of
one case (see below) every warning I encountered yet could be meaningfully
handled, improving the code (conservatively, improving in at least one aspect,
and not impairing in all others). Heavily using templates, this means a bit
more work (for example partial specialisation to treat signed and unsigned
integral types differently), but yet I found that it could be achieved without
adding clutter, but by making the code more "precise".
The only warnings ignored by me are "use of C99 long long integer constant" (coming
for example from boost::integer_traits; this should sooner ore later disappear), and   
"the use of `tmpnam' is dangerous, better use `mkstemp'" (since tmpnam is part of the
C standard; the warning has been appreciated, I looked into the issues, found the
usage correct, and that's it).

There won't be a general solution for this problem, because of the different compilers used
(for example the above assumption that "MSVC level 4 compile without warnings is what we want"
does not hold for me), but I would propose guidelines in the following direction:

1. Syntax errors and the like must be corrected (whether they are minor or not;
see for example that semicolon-discussion some time ago).

2. Everybody should try to eliminate warnings by improving the code, but without
compromising it --- since otherwise this might make it "better" for users of one compiler(-version),
but worse for all other users.

3. For every compiler there is a list of warnings which may not be treated (while all others should be treated).
With this list over time likely one sees that some compiler seem more reasonable (to the programmers in
the boost context) than others. For gcc I would yet only have the C99 long long thing
in the list (whatever people think of tmpnam, I don't think it's a problem for boost),
while otherwise every boost library should treat all other errors.

This third point is likely most important: Over time a standard should be developed, so
that developers can see: Ah, it seems that warnings of this and that compiler should
be treated, and it seems they can be treated reasonably, and perhaps there are also
examples etc. And for other compiler it emerges that certain warnings cannot be handled
or even shouldn't be handled.

This all for the "core code". For the rest (to get rid off the remaining warnings) I think
the special header-solution is appropriate: From the boost side everything was done
(so well, nearly everything) to deliver good code, and the rest then is up to those users
who use a special compiler and care about the warnings: Those users have a special interest,
not shared by other users, and thus they must take some steps themselves (supported by
Boost if possible).

Oliver