|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2007-05-04 20:41:57
on Wed May 02 2007, "Jonathan Franklin" <franklin.jonathan-AT-gmail.com> wrote:
> On 5/2/07, David Abrahams <dave_at_[hidden]> wrote:...
>
>> > If you treat warnings as errors and if bjam has an option to "keep
>> > going" as much as possible, then you get builds as far as they can go
>> > (i.e. all the warnings) and builds fail if there are warnings. Then I
>> > think you don't need to depend on the regression reporting tools for the
>> > rest of time, atleast for this stuff.
>>
>> It would take a lot to convince me to require that Boost builds with
>> all warnings enabled and treated as errors. There are just too many
>> "nuisance" warnings out there, and since GCC gives us no way to
>> explicitly suppress warnings in code, we'd have to write convoluted
>> (and sometimes even inefficient) code just to silence them.
>
>
> This is certainly the case with the MS compiler, who even at lower warning
> levels tends to make spurious comments about your code (not really warnings
> at all).
At least it gives me the #pragmas I need to silence them.
> However with gcc (and possibly other compilers), building w/ -Wall
> -Werror is tenable, and is usually the Right Thing. We have done
> this on the last several (extremely large) projects I have worked
> on.
In my experience it's the Right Thing for certain common coding
styles, but completely wrong for others. For example, GCC has a
warning about a derived class whose base doesn't have a virtual dtor.
It's actually *impossible* (not just inefficient or convoluted) to
implement is_polymorphic without generating that warning.
-- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk