AMDG Patrick Horgan wrote:
Steven Watanabe wrote:
The point is not that fixing warnings would not make Boost better. I'm saying that if the correctness of Boost were the only consideration, the effort spent dealing with warnings could probably be better spent in other ways (Such as dealing with the >850 open trac tickets). The main problem with warnings is not that they indicate bugs, so much as that they make the code less usable because of the noise that they generate for users. Au Contraire! Fixing warnings can quite likely make code better.
I didn't say that it wouldn't.
Whenever I've been involved in a project that generated lots of warnings and the effort was made (often at my encouragement), to clean them up, people found real bugs--things that embarrassed them. They had been told by the compiler about them, but because of the noise, missed the information. I certainly include myself in that. Those embarrassments are why I go with a policy of cleaning up all the warnings. I don't like being surprised by bugs I ignored, and it's especially bad if someone else finds it first. You quickly learn to code differently and don't generate more warnings.
IMHO, the value of suppressing warnings on one compiler is relatively high. When using more compilers, the amount of noise tends to increase more than the number of new problems found.
I notice that much of the discussion from people who don't want to fix warnings has focused on the silly ones. They seem to have been trained by compiler writers to ignore warnings. That's frustrating. Getting rid of your warnings is a good coding practice, and if all of them are the silly ones you're a better coder than I.
I might point out that the ones that we're always arguing about are the silly ones.
If you have virtual functions and no virtual destructor, and you know why, for example, it can be frustrating to get whined at. But, if you provide the virtual destructor, you make it so that someone else maintaining your code years down the road won't be able to easily screw the pooch.
The compiler is not always right in what it thinks you should do. It's the library authors call how to deal with an issue as long as the solution is correct. Boost often uses techniques that do not fit in traditional OO models which is what this warning is designed for. In Christ, Steven Watanabe