John Maddock wrote:
The trouble is, who decides which warnings get suppressed?
IMO a library like boost should IN GENERAL not supress any! [...]
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.
Yes, yes and yes. However, my question was not if it's good to ignore warnings or not. I'm very concerned about releasing a new boost library (1.33.1) that prints a bunch of warnings _in it's own code_ on one of the most popular compilers which definitely communicate to the users that there could be something wrong with this code.
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?
I'm sure boost needs a policy for that but I'm also sure there has to be done something _now_ for 1.33.1 regardless of whatever decision is made to eliminate these warnings properly somewhere in the future. Stefan