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

Subject: Re: [boost] [1.44][Serialization] fails to compile on OSX universal
From: David Irvine (david.irvine_at_[hidden])
Date: 2010-08-21 02:25:24

On Sat, Aug 21, 2010 at 6:09 AM, Emil Dotchevski
<emil_at_[hidden]> wrote:
> 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

I am not any expert in this field but very interested. We try and use
high warning levels and attempt to ensure people implement true fixes
where possible and not code around warnings, such as doing something
to 'use an unused parameter' etc.

In the case you mention about casts, is the case not that the warning
is telling you the compiler thinks it knows what you want but is not
sure, so clarify with a cast or alter your code to do something the
compiler can understand better (which is the preferred route I
imagine)?

There always seems to be debates against warnings that are spurious
but I am of the opinion coding to try and let the compiler understand
what you are doing and using warnings as check would be good practice.
There are many debatable warnings which surely can be handled with
small changes. So if there is 2 ways to do something (there is always
much more) and the compiler complains about one way, why not then code
the other way (in a lot of cases, not all, I do understand some of the
debates). I sometimes wonder if we take high ground on these issues
too quickly when giving a little may help a lot. A good example is
some of the destructor not declared virtual in a base class type
stuff, huge debates and both sides can prove they are correct, however
the compiler still emits the warnings. If you have a clean build and a
warning appears then great, if you already have tones you ignore you
probably wont see the new problem so easily and warnings become less
useful.

I repeat, no expert but interested.