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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk