Re: [boost] [1.44][Serialization] fails to compile on OSX universal

Subject: Re: [boost] [1.44][Serialization] fails to compile on OSX universal
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-08-21 01:09:31

On Fri, Aug 20, 2010 at 9:33 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> Emil Dotchevski wrote:
>> On Fri, Aug 20, 2010 at 5:13 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>>> Emil Dotchevski wrote:
>>>> On Fri, Aug 20, 2010 at 1:02 PM, Robert Ramey <ramey_at_[hidden]>
>>>> wrote:
>>>>> Jeff Flinn wrote:
>>>>>> By the way Robert, thanks for clearing up all of the compiler
>>>>>> warnings in both the lib and in portable_binary_archive over the
>>>>>> last couple of releases.
>>>>>
>>>>> I'm glad you appreciate this. I caused an unintended ripple effect
>>>>> which resulted in much agony - which is likely not over..
>>>>>
>>>>> advice to prospective library developer's - use warning level 4
>>>>> it's cheaper in the long run.
>>>>
>>>> #pragma warning(push,1) on MSVC, and #pragma gcc system_header are
>>>> cheaper.
>>>
>>> hmmm - please expand upon this.
>>
>> I'm not sure if this is a good idea in general but I'm using this in
>> Boost Exception and I'm not aware of any problems it causes. I have
>>
>> #if defined(__GNUC__) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS)
>> #pragma GCC system_header
>> #endif
>> #if defined(_MSC_VER) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS)
>> #pragma warning(push,1)
>> #endif
>>
>> at the top of the header files (and the matching pop for MSVC at the
>> end of the file), so when I build the code I can use whatever warning
>> level is comfortable for me (combined with #define
>> BOOST_EXCEPTION_ENABLE_WARNINGS), while everyone else doesn't see any
>> warnings (I hope.)
>>
>> Of course that is a moot point if you like warning level 4 or the
>> --pedantic stuff in GCC, but I find it very difficult to justify many
>> of the things (for example, casts) people normally do to work around
>> warnings.
>
> When I read you're response, I was thinking it was
> another way to enable maximum warnings.  If I understand you
> correctly, your view is that the warnings should be suppressed even
> when users enable higher levels.
>
> So it seems we've got entirely opposed points of view here.
>
> Personally, I found that the excercise of modifying code to eliminate
> warnings at the level resulted in eliminating a couple
> of potential bugs and hopefully maintaining this will keep
> new ones from creeping it.  I will concede that some warnings
> are over the top and I would like a better way (in GCC) to
> suppress them on a case by case basis.

I agree with you 100%. I wish there was a way to *suppress* a warning
without altering the semantics of the program. But in GCC, there
isn't. So the question is what to do with those pesky warnings that
you think are over the top yet users of the library find useful?

One option is to "fix" them anyway. Unfortunately, a lot of times this
involves casting, and in general I find it ill-advised to use a cast
to suppress a warning. Think about it: casts are used to tell the
compiler to do something it wouldn't normally do because it is
dangerous. This is true for all casts, including the ones people
sprinkle around to "fix" warnings.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode