[boost] Re: Perfect moving (almost)

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-02-09 12:34:26

On Feb 9, 2004, at 11:33 AM, Peter Dimov wrote:

> Peter Dimov wrote:
>> Howard Hinnant wrote:
>>> Reasoning:
>>>
>>> foo(A());
>>>
>>> expands to:
>>>
>>> foo(A(A()));
>>
>> No, it expands to
>>
>>     typedef A const CA;
>>     foo(CA(A()));
>>
>> The difference is that a const_cast<A&> inside foo is now undefined
>> behavior (whereas a direct binding would've made it legal.)

That's not the first time I'm skimmed over one of Rani's posts too 
quickly and lived to regret it.  Thanks for the whap across the nose! 
:-)  <mental note, if Rani writes it, read at least 3 times and not in 
a hurry>

> However (apologies for the follow up to self) the rest of Howard's 
> analysis
> still seems to apply, i.e. the CA temporary is created with A::A(A&&), 
> and
> the A const & parameter of foo is bound directly to that temporary (if 
> not
> elided).

And thanks for the corrected analysis.

Aside:  I'm sure there are dark corners of the standard that would need 
to be closely inspected and perhaps adjusted for the existence of the 
proposed rvalue reference.  Although I'd be thrilled to help, I'm a 
library expert, not a core expert.  The core experts will have to lead 
on the move proposal if it is to succeed.  Once core delivers the 
fundamental tool, I know what I want to do with it in the std::lib.

Further aside:  I'm impressed by the cleverness of the C++98-compatible 
(or nearly so) move techniques that have surfaced (Mojo, 
enable_if-based, and even the old auto_ptr_ref solution).  But one of 
my overriding goals in the language-based move proposal was that move 
logic must be dirt simple to code because Joe Coder needs and wants 
this functionality in his own classes:

class Employee
{
public:
     Employee(const std::string& name)  // copy a name into the class
         : name_(name) {}
     Employee(std::string&& name)       // move a name into the class 
(optimization)
         : name_(move(name)) {}
     ...
     Employee(Employee&& e)             // move an Employee
         : name_(move(e.name_)) ... {}

     // compiler generated copy ctor ok
     ...
private:
     std::string name_;
     ...
};

Dealing explicitly with auxilary auto_ptr_ref-like classes when either 
using move, or when creating movable (and perhaps also copyable) 
classes was recognized as a possibility (just due to the existence of 
auto_ptr) but rejected as too complicated and tedious for general use.

-Howard