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

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-11-02 09:07:08

On Wed, 2 Nov 2005 10:49:29 -0000, John Maddock wrote

>...snip...
> > 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?

I think it's always the same warning for all the deprecated functions (4996).
   On a more practical note, it's tough for us to actually find these b/c we
don't get warnings from the regression tests unless there's an error :-( 

> 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 

Actually I'm not so sure we need a policy.  If we do nothing people will
complain.  When they complain, we point them to the vendor.   Then the vendor
might do something.  Hmm, maybe I should pull my fix out of the HEAD...

> 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?

I agree about that the Microsoft docs could be better.  I also think it is too
early to tell what the best solution is on a Boost-wide basis -- as I say, I
think we don't really know the scope of the problem since authors don't see
warnings on passing tests -- I only know about the date-time problem b/c VC8
actually broke tests.  If we have to write a policy for how library
developers/users should deal with this warning -- well let's just say I'd like
to see the vendor have significant input.

One last thing.  There is no way we should hold 1.33.1 for this issue.  If the
Boost developers decide we are going to 'fix' this issue we can do a 1.33.2
release to address it.  There are critical fixes in 1.33.1 that have been
waiting long enough already...

Jeff