Re: [boost] [review] Formal review of the Smart Container library starts today

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-09-26 18:26:38

On Sep 26, 2004, at 10:28 AM, Pavol Droba wrote:

> The review of the Smart Container library, written by Thorsten Ottosen
> starts today (September 26th, 2004) and runs for 10 days (until
> October 5th, 2004).

This isn't so much a review of the Smart Container library, as it is a 
commentary on how this work relates to move semantics, which isn't 
practical in C++03 (I used to say not possible).  I do not mean to 
comment one way or another on the Smart Container library except to say 
that I know it addresses a real need, and I agree this may be the best 
way to meet it in C++03 (yes, I did read through the docs, nice job 
Thorsten! :-) ).

In C++0X I anticipate that this need will be met with 
container<sole_ptr<T>> (aka container<move_ptr<T>>; I'm experimenting 
with naming alternatives to move_ptr, so please cut me a little slack! 
;-) ).

container<sole_ptr<T>> will have the same overhead as that demonstrated 
in the Smart Container library.  A big difference will be that 
iterators into the container will dereference smart pointers, and not 
the pointed-to elements.  I also anticipate C++0X will contain some 
really slick indirect_iterator types that will transform 
container<sole_ptr<T>>::iterator appropriately.  These will likely be 
heavily influenced by (if not based on) the Boost.Iterator Library.

Assuming things go just peachy, all std::containers will be move-aware 
and thus able to contain move-only types like sole_ptr<T>.  Also I 
would like to see all in-place-mutating std:: sequence algorithms 
(remove_if, unique, etc.) rewritten to deal with ranges of move-only 
types as well.  Such algorithms, if not rewritten for move-only types 
will fail at compile time (as opposed to run time) for move-only types.

container<sole_ptr<T>> is not copyable nor copy-assignable.  
container<sole_ptr<T>> is movable.  Thus sequences of 
container<sole_ptr<T>> (container<container<sole_ptr<T>>>) can also be 
operated on by move-aware in-place-mutating sequence algorithms.

Elements of container<sole_ptr<T>> can't be copied into or out of the 
container with copy syntax:

sole_ptr<T> t = v[i];  // compile time error

But elements can be moved into or out of the container:

sole_ptr<T> t = move(v[i]);
v.push_back(move(t));

Entire containers can be moved from one to the other:

container<sole_ptr<T>> v2(move(v1));

Subranges could be handled with new std::algorithms:

v2.resize(v.size()/2);
std::move(v.begin(), v.begin()+v.size()/2, v2.begin());  // like copy 
but moves

There will be no clone() functionality as in the Smart Container 
library.  One could possibly introduce a new smart pointer:  
clone_ptr<T> which cloned with copy syntax, which would work in today's 
std::containers.  Though they would not be nearly as efficient as Smart 
Container library, or container<sole_ptr<T>>, at least for vector, 
because of the internal copying/cloning.  Such a clone_ptr could be 
made movable though, and thus would be very efficient in a future 
container<clone_ptr<T>>.  This future move-aware 
container<clone_ptr<T>> would not clone objects as it moved them around 
internally, but would clone objects for the purpose of copying them 
into or out of the container, or copying entire containers.

So, all this is put out there in case someone would like to see some of 
this (hopefully) future syntax/semantics influence today's libraries.  
I stop short of saying that it should, or how.

-Howard