Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Nevin Liber (nevin_at_[hidden])
Date: 2011-08-22 01:36:30

On 21 August 2011 21:15, Eric Niebler <eric_at_[hidden]> wrote:

>
> This is the accepted dogma,

For good reason.  These are places that end up getting aggressively
optimized, so code that appears to work today suddenly is broken tomorrow
when the compiler is revved.

However, I might prefer a more
> conservative approach whereby users must opt-in to the memcpy
> implementation instead of making it the default.
>

How often is this thing needed?  The only times you need this is when the
compiler generated move constructor/assignment operators either are deleted
or are doing the wrong thing.  Is that really the time you don't want people
thinking about how to correctly write swap (or better, just write the
correct move constructor and assignment operator).

Even examining the implementation for all your member variables isn't
enough.  The boost::function which holds a boost::bind(..., this, ...) where
the function object is stored inside the boost::function object itself may
now exhibit different semantics than when the function object it is holding
is in the heap.  Ugh.

Way back when, C++ did bitwise copying for the compiler generated copy
operations, and was changed to member wise copying for good reason.  I
really don't want to go back to that world.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]