Daniel Wallin <dalwan01@student.umu.se> writes:
Daniel Frey wrote:
Oh, really? Too bad; I guess this isn't really much of an innovation then. Maybe I misunderstood what you have done, but to me this was the most important part of your code! No strange changes for the user
David Abrahams wrote: like returning special values from functions
I believe this is still needed, for the same reason as in Mojo.
(which is BTW breaking RVO/NRVO and which is what I never liked about Mojo...) and no need for special function signatures as in Mojo, where you had to declare function in a certain unnatural style. IIRC, something like: void f( X& ); void f( mojo::temporary< X >& ); void f( mojo::constant< X >& );
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. 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com