But I will say we still did it - ie we still found it valuable to get to zero warnings.
I read your post carefully and it seems like fixing the warnings didn't uncover any bugs and at least for one warning the fix introduced bugs; +0 for the former, -1 for the latter leaves me wondering what value do you find in fixing the warnings.
Honestly, I can't believe the amount of effort expended on *discussing* this rather than doing something about it. I can say that in my Boost contributions fixing warnings *has* found bugs and I believe improved code quality, further there are some things that don't get warned about (particularly by gcc) which would have made bug-hunting so much easier (for example an implicit narrowing conversion between floating point types). All of which is not to say there aren't situations where I find myself cursing the compiler for issuing stupid busy-body warnings: we all have our favorite list of those. But you know what? It's quicker to fix the warning than it is to spend the time griping about it! To take one example quoted here: the gcc "class does not have a virtual destructor" warning. I've been hit by that in template metaprogramming code, where there is absolutely zero chance that it could ever represent a bug, none the less users complained, I griped, and then in the end I fixed it. What I learned from this was: * It's quicker to fix than gripe. * These often get reported to me multiple times via multiple channels (list, bug report etc), so the quicker it's fixed the less time it takes me dealing with support requests. * The volume of template back-trace can be so high, that even if a complete C++ novice can recognize that the warning is meaningless, the volume of data obscures the *real* problems. * There's no way a user can tell whether this represents a true issue or not without delving into your code and figuring it out for themselves. That's a real concern with this "class does not have a virtual destructor" warning: you may know and understand the context, a user does not: indeed a new Boost user more familiar with OO design than Boost-paradigms may well say to themselves "gees these guys can't even make a destructor virtual when it should be", and just move on to some other library, or worse, reinvent the wheel by writing less good code themselves. Do you expect every new user to Boost to investigate every warning and check it's harmless for themselves? All 13 thousand lines of them from the last build? ;-) And now I must apologize, because this is starting to turn into a rant as well :-( So... here's what I'm going to do: please vote for your favorite worst offenders and I'll start submitting patches and/or making fixes. Any other volunteers? Cheers, John.