Re: [boost] [xpressive] Lots of warnings on VS9

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 
materialize
 - 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:

#include <boost/config/pre.hpp>
code goes here
#include <boost/config/post.hpp>

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.

-- 
Bjørn