From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-02-06 14:46:07
Eric Niebler skrev:
> 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.
It would be usefull to have policies on the issue that are used
throughout boost. To me the following make sence:
Allow code to locally quiet a compilers warnings only if:
- it can be asserted that the issue warned about is not going to
- the warning is plain wrong
All other warnings should be emitted while compiling boost or compiling
with boost headers; unless the user read the docs and follow
instructions on how to make them quiet. As suggested by others, use of
pre/post headers like:
code goes here
used in *all* warning infected boost source files may be the way ahead.
It may prove to be a smart way of allowing a central place for boost
users to disable warnings. They can then determine if they want the
warnings to be disabled globally in their project or only locally for
the boost code. It would be neat if we could override pree/post.hpp
without touching the distribution sources.
Just my 5 cents.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk