Re: [boost] [move] auto-generated operator=

Subject: Re: [boost] [move] auto-generated operator=
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-09-08 05:52:32

David Abrahams escribió:
>> Well, maybe benefits don't outweigh problems... I added that overload so that
>> assignment moves rvalues instead of copying them, 

In the first version of the library we had two overloads ("const T &" 
and "rv<T> &") for copy/move constructor and assignments. But if T& 
operator=(const T&) is defined then:

T produce();

T t;
//...
//Copy assignment called instead of move-assignment!
t = produce();

This is suboptimal for assignments, because a move is replaced with a 
copy. In theory this also happens for copy-constructors but fortunately 
RVO is a much better approach and in practice this problem only happens 
with assignments:

//In theory old approach would also call the copy constructor
//but nearly all modern compilers use RVO.
T t(produce());

That was the state of the library when I first proposed it. Then Klaus 
Trindle proposed an alternative overload set to catch non-const rvalues 
using "const rv<T> &" (the additional ovreloads "were rv<T> &" and "T&" 
--> note that is non-const) and that solves the assignment problem:

http://lists.boost.org/Archives/boost/2009/06/153266.php

However, this approach requires defining a non-const assignment 
operator, so we have a new problem: compiler-generated copy assignment 
takes the argument as non-const T &.

So right know I have two options: the old approach that produces 
suboptimal assignments from non-const rvalues and the newer one that is 
optimal but hurts the compiler generated copy assignment.

We need a third alternative: a new overload set that maintains "const T 
&" and properly catches non-const rvalues.

Best,

Ion