Emil Dotchevski wrote:
On Wed, Nov 4, 2009 at 2:05 PM, Bo Persson <bop@gmb.dk> wrote:
Emil Dotchevski wrote:
On Wed, Nov 4, 2009 at 12:12 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
Unfortunately, recent discussion left me with the impression that few folks care.
It is not about caring, once again the argument is about a personal preference: is the ugliness and decreased readability that is often required to silence a warning reasonable.
I suggest we don't talk in the abstract. Once a specific set of warning options, together with -Werror is in place, you can raise your concerns about any particular warning emitted by any particular compiler, and hopefully, some per-warning-kind agreement can be reached.
I agree that the only way warnings can be addressed effectively is to use -Werror. On the other hand, the idea that a warning is the same as an error challenges my world view. :)
I understand why you say that we can't talk in the abstract. It's downright silly not to fix certain "good" warnings and we, as a community, definitely can agree on a reasonable definition of "good".
However this will not address the issue at hand, which is that people who use higher warning levels will see tons of warnings. A better attitude is http://www.zlib.net/zlib_faq.html#faq35.
Yes, that's a good attitude. However, how are we going to be sure that the code works, when the compiler says it might not?
How we are going to be sure that the code works is not a simple question, but note that "fixing" a warning simply silences the compiler and (ideally) has no effect on the correctness of the code: if the code was buggy, it still is.
(Qualifying the above with "ideally" is necessary because sometimes fixing a lame warning on one platform could also silence a valid warning on another platform.)
I'm not arguing that the code should be obfuscated to satisfy every compiler, but that there could be an official policy that some warnings are really silly and disabled. Perhaps they could be enabled by defining _BOOST_ENABLE_SILLY_MSVC_WARNINGS? Or just document that the code compiles cleanly if I disable the silly warnings. Having Boost compiling at /W2, possibly aiming for /W3, is not impressing on those who's code already compile at /W4 (with a few really silly warnings disabled). Note that VC10 has an additional /Wall level, higher than /W4. :-) Bo Persson