Re: [boost] auto_ptr/move issue

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2003-01-31 10:13:41

On Friday, January 31, 2003, at 07:26  AM, Peter Dimov wrote:

> From: "Howard Hinnant" <hinnant_at_[hidden]>
>>
>> Imho, standardized move syntax/semantics is very close to the top of
>> important issues for C++.  I guess that's why I'm pushing for current
>> smart pointers to get "the right syntax" for move semantics.
>
> But can they get the right syntax without &&?

Close.

> With &&, it's trivial.

Agreed.

"The right syntax" for move, imho, is anything but copy syntax if the 
source is an lvalue.  If the source is an rvalue, then copy syntax for 
move is not only ok, it is actually desirable.

move_ptr<int> source();
...
move_ptr<int> i(source());  // move with copy syntax from rvalue, ok.
move_ptr<int> j(i);  // error, move with copy syntax from lvalue, bad!
move_ptr<int> k(move(i));   // move with move syntax from lvalue, ok.

This much can be achieved in C++98.  It is not trivial, indeed it is a 
pita compared to how easy it should be.  All you have to do is follow 
the auto_ptr design.  Doing so does not get you all of the nice things 
that a language driven move would get you (like movable objects in 
general, containers that can hold non-copyable but movable objects, 
etc.).

But you *can* get away from moving with copy syntax from lvalues!

I presented code under the thread "SmartPtr (Loki) - auto_ptr/move 
c'tor issue" on Jan. 28 which does this.  For easy reference, here is 
the code again, slightly improved:

http://home.twcny.rr.com/hinnant/Utilities/move_ptr

This move_ptr example also provides array support, but names it 
move_ptr<T[]> instead of move_ptr_array.  This is a separate issue and 
has nothing to do with getting "the right syntax" for a move ptr.  So 
you can just ignore that part if your platform doesn't support pts.

-Howard

PS:  There are no copyrights on this code sample, that is intentional.