From: Ed Brey (brey_at_[hidden])
Date: 2001-04-11 08:46:02
From: "Geurt Vos" <G.Vos_at_[hidden]>
> about MSVC, most people will simply leave it at warning
> level 3, which also doesn't issue this conversion warning...
> I never use MSVC at level 4, because it results in way too many
> warning in MS's code, and also generates quite some redundant
> warnings, such as "unreferenced inline function has been removed"
The problem with not using level 4 is that you throw away quite a few
good warnings. For all my projects, I use warning level 4 and include a
header that turns off all bogus warnings; that is, warnings that are
triggered by artifacts present in good code. Additionally, around
include directives for Microsoft headers, which trigger many warnings
that are valuable when applied to end user or boost code, I push to
warning level 3, since I'm not interested in seeing warnings regarding
Microsoft code (I let it fall into the black magic domain).
Boost code, however, is written at a higher level, and ought not be
treated as black magic. It should compile without warning under the
tightest reasonable warning level to prevent bugs, using notation where
necessary to indicate that something like a loss of significant digits
is truly a feature and not a bug (like using [sic] in text).
I'm not sure how many people use warning level 3 versus 4, but it
doesn't really matter. To help the boost code be as error-free as
possible, the more help we can solicit from the compiler the better.
Here's an example of how to one can practically compile under warning
// Disable warnings about artifacts that are present in good code.
#pragma warning(disable: 4097)
#pragma warning(disable: 4127)
// Disable warnings that occur during compilation of system headers.
#pragma warning(push, 3)
#pragma warning(pop) // Allow warning level 4 for our code.
// Reach your hand into the screen to feel the warm fuzzy feeling
// boost is compiling at warning level 4 (minus bogus warnings).
There is a catch with this approach: When boost files include system
headers that have not been previously included by the translation unit,
any of those system headers can trigger non-bogus warnings.
Unfortunately, the C++ standard headers shipped with VC and the STLport
4 headers do this. Fortunately, the solution is simple: include such
headers between the push and pop.
Longer term, I think it would be nice to have boost be completely
warning level friendly, by doing these things:
- Provide a macro that can cause the config.hpp header to disable all
- In each boost file, wrap each sequence of system include directives
where the prolog and epilog do what is appropriate for the system. For
VC, this means a warning push and pop.
The end result is that in many cases the user work happily at warning
level 4, with just 3 extra lines of code.
If there is interest in this, I'd be happy to lay out a more detailed
implementation, including the documented list of overzealous warnings
and documentation of guidelines for library writers.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk