Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Eric Niebler (eric_at_[hidden])
Date: 2011-08-22 11:10:22

On 8/22/2011 1:36 AM, Nevin Liber wrote:
> 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.

Stepanov argues that things like UNDERLYING_TYPE and move_raw should be
part of the Standard Library and guaranteed to work. It could have a
home in Boost, too. There is precedent for having code in Boost that is
non-compliant -- just under compiler switches. Boost.Typeof is
non-compliant. So are parts of Boost.Foreach. And sometimes new
compilers come out that break Boost.Foreach and I have to fix the
compiler work-arounds. So what?

Besides, I think you're getting hung up on the bitwise copy thing.
Stepanov is merely making the point that some things can be implemented
more efficiently with a move-like operation that makes weaker guarantees
than move.

> 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.  

No. Nevin, at this point its obvious to me you haven't read the paper.
Please go read it and then we can talk about the pros and cons.

It is needed when implementing an algorithm for which move is
*inherently* an inadequate tool for the job because it makes guarantees
that are not needed: namely the destructability of the moved-from
object. Preserving that invariant is not needed if you will be moving a
valid value back into the moved-from object before its lifetime ends.

Again, Stepanov does a good job describing all this. Read the paper.

> 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).

Missing the point.

> 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.

And care would be needed to write the move_raw for such an object. Just
as care would be needed to write move contruct/assign and copy
construct/assign for that thing.

> 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.

Nobody is arguing for that.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com