RE: [boost] Re: Perfect Forwarding (almost)
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&);
Ok, but then class X has X (rvalue_ref<X> &rhs) Which IMO is no better.. but each to their own.
==========================================
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.
I think that without using Dave's approach to removing the const T & constructor you have to have all these other MOJO types. Dave's approach does the right thing for non const r-value's returned by functions. Including the operator=() stuff. Without a special Mojo type mojo does not. The beauty of move.cpp is that you only have to modify the class not the functions which you may not have control of. If the question is whether to use inheritence to gain move semantics, I think I answered that already, and it works pretty well. What fails for both of them is that the const &T contructor has to be visible to the compiler even if its not called or used. And whether that is the correct action is the current point of discussion. Yours, -Gary- PS Sorry about the quoting, I dislike the ">"'s with a passion but this email has them for you.
Powell, Gary wrote:
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.
I think that without using Dave's approach to removing the const T & constructor you have to have all these other MOJO types. Dave's approach does the right thing for non const r-value's returned by functions. Including the operator=() stuff. Without a special Mojo type mojo does not.
I don't understand this. The difference between Dave's approach and Mojo is the technique used to discriminate between rvalues and const lvalues. struct X : mojo<X> { X(X&); X(temporary<X>); X(constant<X>); // HERE }; struct X : new_way<X> { X(X&); X(temporary<X>); template<class T> X(T&, typename enable_same<X const, T>::type = 0); // HERE };
The beauty of move.cpp is that you only have to modify the class not the functions which you may not have control of.
This is true for Mojo as well, except for working around const& binding.
If the question is whether to use inheritence to gain move semantics, I think I answered that already, and it works pretty well.
What fails for both of them is that the const &T contructor has to be visible to the compiler even if its not called or used. And whether that is the correct action is the current point of discussion.
Right. And if it isn't the correct action both ways will work equally well. -- Daniel Wallin
"Powell, Gary" <powellg@amazon.com> writes:
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&);
Ok, but then class X has
X (rvalue_ref<X> &rhs)
It has X(rvalue<X> rhs) or X(rvalue<X> const& rhs) instead of X(X::ref)
Which IMO is no better.. but each to their own.
It's slightly better because no explicit casts are needed.
==========================================
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.
I think that without using Dave's approach to removing the const T & constructor you have to have all these other MOJO types. Dave's approach does the right thing for non const r-value's returned by functions. Including the operator=() stuff. Without a special Mojo type mojo does not.
As far as I can tell, Daniel is correct.
The beauty of move.cpp is that you only have to modify the class not the functions which you may not have control of.
If it's true that you have to modify functions which want to accept mojo'ed types, its not clear to me why you'd do that.
If the question is whether to use inheritence to gain move semantics, I think I answered that already, and it works pretty well.
What fails for both of them is that the const &T contructor has to be visible to the compiler even if its not called or used.
On some compilers, I guess.
And whether that is the correct action is the current point of discussion.
Yep.
Yours, -Gary-
PS Sorry about the quoting, I dislike the ">"'s with a passion but this email has them for you.
Please do it for me, too. You can use other characters, like "|" for example, but ">" is standard. Mailers colorize and reformat based on quoting levels by detecting these characters in the left-hand column (and some probably only detect ">"). If you don't use standard quoting, you make your messages harder to read and manipulate for almost everyone, and anyone who wants to respond to your messages in a way that's friendly to others has to go back and repair the problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Daniel Wallin -
David Abrahams -
Powell, Gary