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

From: John Maddock (john_at_[hidden])
Date: 2005-11-02 11:43:11

>> 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 :-(

I know: that's one feature that's missing from the new regression test 
harness that we had in the old one.

However, once VC8 express is available as a general download I expect more 
folks will be able to test on their own machines.

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

Understood, folks are sure going to complain though...

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

Violent agreement all round then!

John.