$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [1.44][Serialization] fails to compile on OSX universal
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-08-23 12:46:56
Stewart, Robert wrote:
> Emil Dotchevski wrote:
>>
>> 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.
>
> +1
>
>> 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.
>
> In many cases, the casts are to make explicit what is otherwise
> implicit and, in so doing, quiet the warning. Addressing such
> warnings, however, should include considering that the implicit
> behavior was not actually desirable. In that case, one should employ
> mitigating strategies other than casts, such as Robert did.
>
> Many other alterations are appropriate to quiet warnings and
> relatively few changes involve altogether different code that is
> buggy or questionable, IME. If one finds an unacceptable change
> necessary to quiet a warning, then strong-arm tactics like GCC's
> system header pragma are certainly worth consideration. That
> approach is not without problems, however. From the point you
> introduce that pragma, there will be no warnings from the affected
> header without establishing a careful maintenance protocol to disable
> the pragma whenever the code changes, verify each and every warning,
> and then reenable the pragma, just to determine if the code change
> triggered a warning that shouldn't be suppressed. That's hardly a
> good use of maintenance time, so eliminating warnings is the best
> approach for all reasonable cases.
FYI - after I did this, I was left with a few warnings still. I couldn't
quiet them in a way that I found acceptable so I just left them in.
The main one was comparison between signed/unsigned ints in a
few cases. So I think the goal of warning elimination is not
worth persuing. The goal should be warning minimization. From
my perspective this is doable and helpful.
Robert Ramey