[boost] Re: Perfect Forwarding (almost)

From: David Abrahams (dave_at_[hidden])
Date: 2004-02-11 22:49:25

"Powell, Gary" <powellg_at_[hidden]> 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