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