On 30.08.2010 15:12, Stewart, Robert wrote:
Artyom wrote:
IMHO: let library developer decide what to disable and what policy he should use. Developer that respects himself would code the way the code compiles with severe warning level.
Boost is thought of as a whole made of parts. If the parts differ wildly in how things are addressed, the whole suffers. That's why we have high documentation standards for all Boost libraries, for example. Consequently, without some minimum standard for warnings, there may be too much variation.
There should be guidelines on things to avoid when trying to fix warnings. Emil's favorite is to avoid casts because they bypass the implicit type conversion system in the language and can hide problems. I don't agree entirely with his concerns, but there is value in what he says.
We need guidelines that prescribe and others that proscribe to ensure best practice.
I think, you both are right here. Maximum level warnings are simply not practical, at least with compilers I dealt with. I honestly don't understand those who think that warning-free code is somehow more solid than the code which emits warnings. Writing code that emits no warnings on all compilers Boost supports is a nightmare and I would even say that the quality of such code would be worse in some respect. Adding casts, pragmas, removing parameter names and adding conditional compilation to avoid "unsafe" functions - all this makes the code more complicated and harder to maintain and understand. I don't like warnings and I'm for fixing them - but only up to the point when it doesn't hurt the code clarity. This usually amounts up to /W3 on MSVC and default warning settings on GCC. Some warnings, like signed/unsigned comparison and uninitialized variables, often indicate real bugs and should be taken care of. I'd suggest to make a list of such warnings (or warning settings on particular compilers) and try to avoid them in Boost. Note that I'm against making this list of all warnings at the highest levels and as such I'm not offering a solution for those seeking for a warning-free Boost. I think, the list will be quite short, in fact. But by following this guideline we will improve Boost code quality without paying much time and nerves. I think, Paul's Wiki page is a good starting point in this direction. On the original topic: * I don't think that adding the ability to mask out all Boost warnings is of much use. After all, if users are trying to make their code warning-free, they probably want to make the code more safe and bug-free. Hiding warnings in libraries they use (Boost included) looks like a disservice, since the warnings may be valid. * If a user encounters valid warnings with Boost, he should be encouraged to report them back so that we could fix them in Boost code. In case if the warning is spurious and the developer doesn't want to cripple the code to work it around, the user is usually able to mask it away for Boost locally (by pragmas or by warning settings on his particular compiler; on GCC one could even use -isystem). That's why I don't think that adding the policy is a good idea for Boost in general. However, particular library developers may offer this feature of their own libraries, on their free will.