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