Re: [boost] [move] move assignment from lvalue returned by func (was: one more dumb question)

Subject: Re: [boost] [move] move assignment from lvalue returned by func (was: one more dumb question)
From: DE (satan66613_at_[hidden])
Date: 2010-02-26 10:47:06

on 26.02.2010 at 0:20
 Jeffrey Hellrung wrote :
> Fortunately, you don't have to worry about the return type of foo; just
> return by value, as you normally would.  Return Value Optimization (RVO)
> (or whatever mechanism you want to attribute this to) takes care of 
> eliding the copy between the "return" in foo and the call site.  So now
> you just need to worry about which operator= the assignment will call.
this' clear

> Currently, I believe, if you use the move-enabling macros in Boost.Move,
> then the move assignment operator of my_type will be chosen for the 
> assignment operation, rather than the copy assignment operator.  The 
> "trick" that Boost.Move employs is to declare the copy assignment 
> operators as operator=(T&) and operator=(const rv<T>&); and the move 
> assignment operator as operator=(rv<T>&).  The end result is that 
> rvalues of type T bind to the move assignment operator, while all 
> lvalues will bind to one of the copy assignment operators.  Thus, the 
> above assignment, "a = foo()", will move assign.
i can't fully understand this so far
on one hand there can be functions returning 'type' or 'const type'
how current implementation interact with it?
on the other hand there is a (widespread?) relaxation of the standard
according to which a reference can be bound to an lvalue (at least
msvc80 provide it)
does the implementation handle it?
i'm not talking about non-canonical form of the copy assignment (i
mean 'operator=(const t&)')...

> There has been some discussion, however, that this mechanism has 
> undesirable side effects, one of which is the "poisoning" of the 
> auto-generated copy assignment operator for all classes that enclose a
> class (inheritance or member object) that use a move-enabling macro. 
> The auto-generated copy assignment operator will take its parameter by
> reference to non-const, which is Bad.
indeed, but personally i don't consider this a big issue

> The alternative is, for move-enabled classes, to write a single 
> assignment operator accepting its parameter by value.  This is safe, 
> specifically addressing the above "poisoning" problem, if non-optimal 
> for classes with member objects for which copying and moving is identical.

> I've actually experimented with different alternatives to the 
> move-enabling macros (as well as how to implement forwarding), and at 
> some point soon will present my thoughts to Ion on what I think could be
> done.
i bet you tried simpler solutions
then why not to choose a simpler one?

> - Jeff
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

-- 
Pavel