David Abrahams wrote:
Daniel Wallin <dalwan01@student.umu.se> 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& constructor) http://tinyurl.com/3f6sw X x; 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 references. -- Daniel Wallin