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
>> 1. template typedef's are a probable future language feature.
>> 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
> 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
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> 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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk