Boost logo

Boost :

From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2008-02-06 12:34:52


On 05/02/2008, Eric Niebler <eric_at_[hidden]> wrote:
>
> Robert Dailey wrote:
> > On Feb 5, 2008 3:11 PM, Eric Niebler <eric_at_[hidden]> wrote:
> >> I'm against Boost globally disabling any warnings. IMO, it's really the
> >> user's call.
> >
> > I believe boost should keep itself clean, whether that means fixing
> warnings
> > properly or hiding them via #pragma directives. It's my responsibility
> to
> > hide my own warnings in my own source files, not in boosts. That's just
> my
> > opinion on the subject of warnings.
>
> An organization may have a policy to disallow use of "unsafe" constructs
> that could lead to unchecked buffer overflows. They would want actually
> want to know if Boost headers were using raw pointers as output
> iterators, for instance. If Boost disables these warnings for its own
> code, it presents a barrier to adoption for these organizations.
>
> If Boost adopts a policy whereby noisy warnings are disabled for Boost
> code, there should at least be a well-documented method for re-enabling
> these warnings for the people who care about them. The concern is that,
> since nobody reads the docs, and since the lack of warnings actually
> hides the issue, it could lead to a false sense of security. It seems
> like the wrong default to me.

The attached patch attempts to globally silence these warnings unless
--show-all-warnings is passed on the command line. It should only work for
the main boost build process and for user builds that explicitly use a
library's build/Jamfile.v2 and bjam. Also, there's a warning emitted that
explains what's happening.

I'm sure there are better ways of doing this, but the patch is really simple
and seems to work as expected.

It's there if anyone finds it useful.

Cheers,
Darren

P.S. I've not got access to MSVC8.0 and I seem to remember there being three
defines you needed to supply but I can't remember what they all were.




Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk