[boost] Re: Yo, move semantics anyone?

From: David Abrahams (dave_at_[hidden])
Date: 2004-04-14 14:29:54

Joaquín Mª López Muñoz <joaquin_at_[hidden]> writes:

> Ok, I must be misunderstanding your comment about VRO. So,
> what does this mean?
>
> "Many compilers implement enough (N)RVO that implicit moving from"
> "rvalues is unneccessary"

The point of my library is to provide:

1. a uniform way for callees to detect rvalue arguments (use
   move_from<X> as an argument and make the lvalue overload templated
   with enable_if_same)

2. a uniform way to declare that an lvalue argument may be moved from
   (pass it as move(x)).

3. Allow classes to be written that automatically use move semantics
   when rvalues would ordinarily be copied, as in when an object is
   returned from a function (provide a constructor accepting
   move_from<X> and a conversion to move_from<X> or inherit from
   movable<X>).  That's what I mean by "implicit moving from rvalues".

4. Provide a simple way to declare the constructor and assignment
   operator overloads needed to make movable classes also copyable
   (BOOST_LVALUE_COPY_CTOR and BOOST_LVALUE_ASSIGN).

Compilers that implement both URVO and NRVO seem to never copy an
rvalue anyway, so they don't need part 3 except in order to explicit
moving of lvalues.

>> Try the move.cpp test with --verbose-test on GCC to see what I mean.
>>
>> > * In those classes with fast swap, is this a right approach to implement
>> > the move constructor?
>> >
>> > X(move_from<X> rhs)
>> > {
>> >   this.swap(rhs);
>> > }
>>
>> Not usually; that will default-initialize all bases and members before
>> doing the swap.
>>
>
> Yep, but I'm thinking about a container, where initializing to an
> empy sequence is insignificant compared to copying the
> whole elements of rhs. 

In that case, yes, that would be an appropriate move constructor.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com