Subject: Re: [boost] [1.44][Serialization] fails to compile on OSX universal
From: David Irvine (david.irvine_at_[hidden])
Date: 2010-08-21 13:04:37
On Sat, Aug 21, 2010 at 6:08 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> 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
>
>
>
> _______________________________________________
This looks like a good move and I think very efficient, although I
think perhaps for completeness you should declare the assignment
operator private, to prevent the compiler declaring if for you.