Subject: Re: [boost] Official warnings policy?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-11-04 19:58:09
On Wed, Nov 4, 2009 at 3:54 PM, Mateusz Loskot <mateusz_at_[hidden]> wrote:
> Emil Dotchevski wrote:
>> 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.
> This attitude is a polite excuse with no practical rationale behind.
> One may ask, how they can make sure their code works with my compiler
> if I see number of warnings that suggest some dirty hacks around
> aliasing are used, so potential undefined behaviour is handing in the air.
Yes, but not all warnings are like that. Many warnings inform about
tricky semantics or tricky side effects, like "ohai operator| has very
low precedence, consider using parens." Some warnings are plain wrong,
like the "you don't have a virtual destructor!!!!!" warning in GCC.
Yet others help enforce coding standards.
Secondly, sometimes practicality is the name of the game, and
theoretical failures are just that, theoretical. For example, I try to
be careful but I wouldn't bet that all of my code will behave on a
platform where CHAR_BIT isn't 8.
> However, "never ignore" does not necessary mean always fix your code to
> silent warnings. It means that if warning is reported, it should be
> analysed what the complain is about and action should be taken: fix code
> or silent warning or ignore. Ignore after check is fine, as long as
> "never ignore warnings" approach is followed.
Fine, but this is not what the issue is about, I don't think. The
problem is that there are companies that require -Wall -Werror or some
Otherwise, what you're describing sounds like common sense to me.
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk