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. 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,
Steven Watanabe wrote: 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. 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. 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. Patrick