Powell, Gary wrote:
Nice. I think we'd implement a "move" function which could handle that explicitly in any real implementation:
Y(ref rhs) : X( move(*rhs.p) ) // <== here , id(++cnt) , owner(rhs.p->owner) { std::cout << "MOVE #" << id << " <== #" << rhs.p->id << std::endl; rhs.p->owner = false; assert(owner); } ========================================== Gary > Thank you!
I must be dense but I'm not seeing how a move function would give us the right type.
template<class T> ??? move(T &) {... }
X( move (*rhs.p) ) // T is a Y // calls X copy if move returns T *.
and we need
X ( X::ref) // and X::ref only takes a X * and X::ref private to X.
What am I missing here?
That ref doesn't need to be private in X? template<class T> rvalue_ref<T> move(T&);
==========================================
All in all I like it better than the MOJO soln which IMO was much more invasive.
What about the MOJO approach seems more invasive to you? =========================================== Gary > Well you need to modify both the functions you use and the class. And the class requires more modification.
It's only more modification because you added a whole lot of assignment operators, it's not like the generated one will do the right thing with the new approach.
// Special return type from an object to use it.... // test with binary operator + ::mojo::fnresult<Y> operator +(Y lhs, Y const &rhs) { return lhs; // do the addition here }
vs with move.cpp, no special type necessary.... Y operator + (Y lhs, Y const &rhs){ return lhs; // do the addition here. }
fnresult is only used to work around the rvalue to const& binding problem. I'm not sure I understand what Rani has been saying, but it seems like whatever applies here would apply to Mojo as well. So AFAICT: if it works with Dave's code, it should work with Mojo. I might as well be wrong though. BTW, your quoting style is _really_ annoying. Please try to use standard quoting. -- Daniel Wallin