Re: [boost] [also 1.33.1] disabling warings (was VC8 deprecated library functions and impact on boost)

From: John Maddock (john_at_[hidden])
Date: 2005-11-02 05:49:29

> It would be a good idea to have a <boost/warnings/push.hpp> and
> <boost/warnings/pop.hpp> that would disable then restore common warnings
> that occur in boost. You would then have
>
> #include <boost/warnings/push.hpp>
> // ...
> #include <boost/warnings/pop.hpp>
>
> in the affected Boost headers. This would then keep all the warning
> logic in one place, offer a more elegant solution to the VC8 deprecated
> function problem and help users of Boost that enable all warnings and
> warnings as errors.
>
> This idea was proposed previously, but there wasn't enough interest in
> it. If this seems a reasomable solution, I could look at providing an
> implementation of these headers with support for the Microsoft, Borland
> and Metrowerks compilers as it can be annoying to do:
>
> #pragma warnings ( push )
> #pragma warnings ( disable : nnnn ) // disable some warning
> #include <boost-header>
> #pragma warnings ( pop )
>
> whenever I want to include a boost header.

The trouble is, who decides which warnings get suppressed?

Or to put it another way, every warning needs a number one human eyeball to 
look over the code and decide whether there is an issue or not.

And yes, many of the common, annoying warnings do sometimes result in 
genuine fixes to code.  I'm sure this will be true of the new "deprecated" 
warnings as well, even though they are truly annoying in many cases.

So... while we clearly need a policy to deal with this, I would rather it 
was something that encouraged authors to "do the right thing", which 
probably varies case by case.  It would also help if Microsoft had more 
documentation on this: anyone know how to mark a user defined iterator as 
"unbounded" for example?

John.