RE: [boost] Re: Perfect Forwarding (almost)

From: Powell, Gary (powellg_at_[hidden])
Date: 2004-02-11 19:49:24

> > 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.