Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros

Subject: Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2010-05-14 04:19:11

On 12/05/2010 17:37, Jeffrey Lee Hellrung, Jr. wrote:
>
> My intention is not to exclude this aim, I only consider it secondary to
> defining an agreed-upon protocol for data structures and algorithms to
> interoperate in a move-aware fashion within c++03.

Ok, perfect, so what do you think that protocol should look like? Just 
trying to get which requirements would be essential for different 
reviewers and try to merge them.

> Precisely why the requirements of a movable type should be explicitly
> defined, independent of how the move emulation is superficially effected
> in the code (i.e., which macro you use). As long as T is efficiently
> constructable and assignable from rvalues and (emulated) rvalue
> references (rv<T>& or T&&), the algorithm shouldn't care how the move
> emulation is actually effected within T.

Yes, algorithms should just need that, and a few functions (move(), 
forward()) to do their work. They shouldn't care about macros or 
implementation details.

> I would just like some confidence in knowing what it means to be
> "compatible". As it stands now, today we'll use rv<T>& to emulate an
> rvalue reference, and tomorrow you might change the code to use sw<T>&
> to emulate an rvalue reference, or something even more radical. Who
> knows? There's (currently) nothing in the interface of (proposed)
> Boost.Move to suggest that the emulation machinery is nothing more than
> an implementation detail, which is problematic if code tries to enable
> move emulation in some alternative way, e.g., conditionally.

Ok. I don't know if someone will find a better emulation implementation. 
If we believe that we know enough C++03 to say rv<T> is the beste 
possible approach, there is no problem in pushing this outside the 
implementation detail. But we are ties with this implementation forever, 
and we should be aware of that limitation.

Best,

Ion