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.
> 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
i bet you tried simpler solutions
then why not to choose a simpler one?
> - Jeff
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk