Boost logo

Boost :

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]);

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:

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at