
Andrey Semashev wrote:
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.
This is from the library writer's perspective. What about the potential library user? If I have a code base that compiles cleanly with MSVC at /W4, I really don't like to lower my settings to /W3 or /W2 just because the library should also be compilable by SunStudio or a 10 year old Borland compiler. What do I care? :-) The curse of a portable library falls on a user who's code isn't portable anyway. Bo Persson