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

Subject: Re: [boost] [1.44][Serialization] fails to compile on OSX universal
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-08-21 13:08:09

Dave Abrahams wrote:
> Sent from my iPhone
>
> On Aug 20, 2010, at 9:09 PM, Emil Dotchevski
> <emil_at_[hidden]> wrote:
>
>> 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.
>
> True, but you can often avoid those casts by allowing (presumably
> safer) implicit conversions to do the same work,e.g. instead of
> static_cast<Base&>(derived), declare and initialize a named Base&.

Here is what I did.

I had a bunch of warnings that I could have fixed with casts.  In some
cases I did.  But in most cases I felt I was "Hiding the problem" by
puting in a cast.

What I ended up doing in many cases was make a special type such as

// a special type of integer.  This is used as an 'id" so it makes no
// sense to apply arithmetic operation or to compare it to other integers
// which are not this type of id
class special_type {
    int m_i;
public:
    // trap uninitialized values
    special_type(int i) : m_i(i) {}
    // trap erroneous comparisons
    bool operator==(const & special_type rhs) const {
        return m_i == rhs.m_i
   }
   // don't permit id to change - don't define assignment
   // but copying is ok
   special_type(const special_type & s) : m_i(s.m_i) ;
};

Now compile your program and all the warning are now errors.
(plus a whole new raft of errors).  Then start doing things like

replace
    int id;
    if(id == original_id)
        ...

with
    special_type id(... ah think about this - this is a good thing);
    if(id == original_id)
        ...

Now

a) your warnings disappear
b) you might have fixed a bug
c) you have set things up to avoid future bugs
d) at no cost in execution time

This might look like a lot of work.  But it really isn't.  You
have to think carefully about what kind of operations you
want to actually permit and/or trap which is some work.
But fixing the generated errors is very easy as the whole
system almost tells you what to fix.  I can do it while participating
in an otherwise mind numbing phone conference.  In fact
it's a good way to do as it makes me sound less disinterested.

Robert Ramey