Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk