[boost] Re: [boost] Re: [boost] Curaçao: reaction to smart pointer

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-04-30 22:18:16

On Tuesday, April 30, 2002, at 08:50  PM, Gennadiy Rozental wrote:

>
> "Howard Hinnant" <hinnant_at_[hidden]> wrote in message
> news:3B46B3BC-5C81-11D6-
>> 1.  template typedef's are a probable future language feature.  
>> Assuming
>> we have that, how does that change the picture?  Are there unforeseen
>> issues with template typedef's that will make them more or less useful
>> than expected?
>
> It may simplify design of smart_ptr a bit and also would be of great 
> help in
> defining hares_ptr, scoped_ptr  ... in terms od policy-based smart_ptr

Yes, that is my guess as well.  But I'm not yet aware of any 
*implementation* of template typedef's.  I'm probably just being a 
nervous nellie, but show me the cash man (just being rhetorical).  I 
have high hopes for template typedef's increasing the usability of 
policy based designs.  But I'm not willing to standardize something 
based on that hope.  On the other hand, the promise sounds good enough 
that I'm not willing to settle for less either.  So there we sit ... 
between a rock and a hard place. ;-)

>> 2.  How will the introduction of move semantics affect smart pointers?
>
> sorry gor my ignorance, but could you clarify on 'move semantics' and 
> how
> does it affect smart_ptr interface?

Move semantics refers to a general concept whereby resources (e.g. 
memory ownership) can be transferred from one object to another.  The 
current std::lib already has several examples of move semantics:  swap 
on all of the containers, list::splice, and auto_ptr copy and 
assignment.  What is lacking is standardized syntax, and standardized 
semantics indicating a one-way only transfer of resources (as opposed to 
swap which is a bidirectional exchange).

auto_ptr is the role model here.  But what I'm alluding to is something 
that would transfer ownership as auto_ptr does, yet not do it with 
syntax that looked like a copy operation.  And said smart pointer might 
not support copy semantics (copy constructor and copy assignment 
declared private).  Some have suggested that the syntax might look like:

smart_ptr<T> a(...);  // create a smart pointer
smart_ptr<T> b = move(a);  // transfer a's resources to b

but:

smart_ptr<T> b = a;  // compile-time (or link-time) error, copy 
constructor not supported

It is looking like a useful exception might be moving from an rvalue:

smart_ptr<T> source();
...
smart_ptr<T> a = source();  // ok, transfer from rvalue implicitly moves
smart_ptr<T> a = move(source());  // also ok, does same thing as previous

Given a smart_ptr that could move, but not copy, and given a container 
(say vector) that could detect move support and use it, then 
vector<smart_ptr<T> > becomes a possibility even though smart_ptr is 
neither copy constructible nor assignable.   One could move objects into 
and out of vector, instead of copy them in and out.  vector could move 
objects during insert and erase, instead of using copy.  
vector<smart_ptr<T> > would not be assignable nor copy constructible.  
But it should be moveable!

And vector<smart_ptr<T> > would be safe.  Unsafe operations that might 
try to silently move resources by masquerading as copy operations would 
be caught at compile time.  The classic example that motivated the 
current auto_ptr design:  std::sort(v.begin(), v.end()) would not 
necessarily work, but it might (depending upon the implementation).  If 
it failed, it would fail at compile-time, not at run-time (copy not 
accessible).  Future revisions to the std::sort spec might mandate that 
it work.

This is all rather preliminary, no working implementations exist to my 
knowledge.  But it is not pie in the sky either.  Myself and others are 
working hard to make move semantics a reality for C++0X.  In the 
preliminary stages we are in, things look promising, but there are no 
guarantees here.  Move has not even been presented to the C++ committee 
yet.

If move semantics become a reality, there are implications across both 
std and user-defined objects, though backward compatibility should not 
be a problem.  All existing classes will be move ignorant.  If move 
happens, I would like to see a smart pointer and containers that can 
take advantage of it.  This does not mean that work on smart pointers 
should halt until move is settled.  But it does mean that I'm not 
anxious to standardize more types without considering the implications 
of move semantics.

-Howard