Re: [boost] Official warnings policy?

Subject: Re: [boost] Official warnings policy?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-11-06 08:35:24

Emil Dotchevski wrote:
> On Thu, Nov 5, 2009 at 10:26 AM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> wrote:
> >
> > There is clearly a problem with the warnings generated by
> > Boost code.
> > Addressing that problem makes Boost more usable and might even
> > make it usable where it now is not.  That's hardly silly.
>
> At least to me, it isn't at all clear that there is a problem with
> warnings generated by Boost.

My builds are complicated by this issue.  I strive for warning free builds for the many reasons enumerated in this discussion.  The warnings are a problem for me and those that use my code.

> Sure, some companies opt not to use Boost, but this doesn't
> necessarily indicate a problem in Boost. I've worked at several
> companies where STL was banned yet they spent countless hours
> implementing STL features and then countless hours implementing
> optimizations in these features that were readily implemented in STL.
> However, I don't blame their poor judgment on STL.

There are other companies that have found that zero-warning builds are wise and can't tolerate the noise introduced by using Boost.  That's their decision, of course, but since Boost *can* do better, shouldn't it?  Shouldn't Boost set a good example?

> What about companies that *do* use Boost? If we are to prioritize our
> efforts to provide the best service to them, should we be fixing
> warnings or improving our testing procedures? Should we be fixing
> warnings in general or working on tickets?

That's a false dichotomy.  We use Boost and we would be well served by eliminating the warnings that causes.  Improved testing means that we don't have to discover and report bugs because tests would have found them earlier, so that's certainly helpful.  Addressing bug tickets is necessary to be responsive to your customers.  All of these things are valuable.  You must prioritize them, of course.

Note, however, that when working on a particular part of a library to address a new test failure or fix a reported bug, you can eliminate some warnings, too.  Eventually, you'll address all known warnings or will have no bugs to fix and no test failures to address and can eliminate the remaining warnings instead.

I must acknowledge that dealing with warnings takes time; I don't mean to trivialize that.  Nevertheless, a *goal* of zero warnings on the primary compilers, with standardized warnings flags, is worthwhile for numerous reasons.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.