Boost logo

Boost :

Subject: Re: [boost] Are warnings acceptable artifacts from builds?
From: Brian Ravnsgaard Riis (brian_at_[hidden])
Date: 2009-09-11 15:04:57

Hash: SHA1

Emil Dotchevski skrev:
> On Fri, Sep 11, 2009 at 3:06 AM, Brian Ravnsgaard Riis
> <brian_at_[hidden]> wrote:
>> Actually, I believe they're claiming that they more heavily rely on a
>> rather impressive unit- and regression testing scheme than on compiler
>> warnings. No warning has ever informed them of a bug that their
>> regression tests would not have caught.
> If the "we want no warnings dammit" crowd main argument is "at my
> company we have zero-warnings policy, we can't do anything about it"
> then arguing whether or not any particular warning should be addressed
> is pointless (OTOH, I'd bet that no company has zero-warnings policy
> because some warnings can't be dealt with any other way but by
> disabling them.)

Uhm.. Which wasn't actually what I was trying to address. My comment was
solely pointed at the SQLite-crowd comment, that they believe warnings
are not just meaningless, but dangerous.

My position (should you want it) is that warnings should not be ignored
*out of hand*, and if you do ignore it, you should try to shut the
compiler up. Having loads of warnings scroll by that you "know" do no
real harm lowers your attention to warnings in general, so you're less
likely to notice when something serious shows up, which it *will* sooner
or later.

I'm not saying that the boost libraries should be warning-free at all
warning levels on all compilers; this is nigh impossible in the real
world. I *do* believe that, as Volodya mentioned, compiling error-free
on a select set of compilers at a given (read: reasonable) warning level
should be possible. Obviously G++ and MSVC are what I'm thinking about
here, but both this and the given warning level should be stated
somewhere in connection with the coding standards.

Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla -


Boost list run by bdawes at, gregod at, cpdaniel at, john at