From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2004-02-09 10:39:19
David Abrahams wrote:
> Daniel Wallin <dalwan01_at_[hidden]> writes:
>>You only need to do that if you want an rvalue reference as a parameter.
>>Normally you would just take the parameter by value and trust the move
>>constructor. The same thing needs to be done with Dave's version and
>>also with some future addition of rvalue-references to C++.
>> void f(X); // can move automatically with move constructor
>> // in both Andrei's and Dave's code
>> void f(mojo::temporary<X> x); // rvalue ref in Andrei's code
>> void f(X::ref x); // rvalue ref in Dave's code
> Not exactly.
> void f(X const&)
> Currently accepts rvalues of ordinary copyable classes, and that
> wouldn't change if the rvalue reference (&&) notation were introduced.
> The problem is that in order to use my technique (or Andrei's),
> movable classes can't be "ordinary copyable" classes; they must have
> a copy ctor taking a non-const rhs. At least with a language
> extension, an "ordinary copyable" class can also be movable.
Right. FWIW, I would love to see this rule go away.
> One thing I think we overlooked in the move proposal, though, is the
> fact that "only movable and not copyable" class rvalues *still* can't
> legally be passed where a const reference is expected, unless the rule
> in question is lifted. That seems like a problem to me.
That is true if the class would declare regular move constructors with
rvalue references. But doesn't the trick used to implement move_ptr
apply with the new rvalue references as well? (moving with const&
X y(static_cast<X&&>(x)); // should bind to X(X const&) and not
// generate an error?
So technically the rule doesn't need to be lifted if we get rvalue
-- Daniel Wallin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk