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

Subject: Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-05-12 11:37:25

On 5/12/2010 3:16 AM, Ion Gaztañaga wrote:
> On 11/05/2010 8:48, Jeffrey Lee Hellrung, Jr. wrote:
>
>> In my opinion, *the* primary goal of this library is to provide a
>> standardized convention by which data structures and algorithms within
>> and outside of boost can make use of move semantics in c++03 (there is
>> already such a convention in c++0x).
>
> The aim is also to provide a portable syntax between C++0x and C++03
> compilers, that's why I consider the macros necessary. I would like to
> offer a syntax any novice could easily understand.

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.

> I also understand your position when you say:
>
>  > This means, for
>> example, that, as an author of some class, I am not restricted to
>> using the macros provided by this library to enable move emulation,
>> or the forwarding functions this library provides, or whatever else,
>> if they don't meet my requirements.
>
> but I, as a writer of an algorithm, would like to know how the emulation
> works and what should I expect when assigning temporary copyable and
> movable classes. If the performance depends on the emulation used by the
> author, maybe I can't design the algorithm optimal for both C++0x and
> C++03.

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.

>> I believe an itemization of the
>> nitty-gritty requirements that a class must satisfy to be move-aware
>> will encourage alternative, more targeted methods to enable move
>> emulation while remaining inter-compatible with each other.
>
> As long as they are compatible, there is no problem, but I think having
> a C++0x-like syntax for move emulation is positive. Maybe both
> approaches should be available, the macro-based one for average users
> without forbidding the use of alternative approaches.

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.

Don't get me wrong, *some* standard macro should be supplied that 
enables move emulation with the same syntax in both c++03 and c++0x 
(and, based on the arguments in my previous email, this should be, at 
least, the "safe"/"friendly" version, and, optionally, the "optimal" one 
as well).  Like you said, I think, at the same time, the emulation 
machinery should be exposed in the interface to allow for alternative 
approaches.

> Thanks for your comments, best,
>
> Ion

- Jeff