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
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
> Thanks for your comments, best,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk