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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-09-27 01:46:31

"Howard Hinnant" <hinnant_at_[hidden]> wrote in message
news:83B293FA-1013-11D9-9D49-003065D18932_at_twcny.rr.com...
| 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! :-) ).

Thanks  :-)

| 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.

I assume that there will still be some differences:

1. a large part of the in this library is indirected, eg. front() in
container<sole_ptr<T>> would return
    sole_ptr<T>

2. release() and clone() can be made faster by moving instead of using an
std::auto_ptr<> as today

3. your map iterators would be different

4. If you do intend that the interface of container<sole_ptr<T>> has the same
interface as container<T>,
    then you loose the domain specific interface and the Clonable metaphor

| 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.

That would be nice. If all mutating algorithms would be guaranteed to call
a swap and never use a copy-constructor, I think we could make an iterator
for the smart containers that was indirected *and* did "the right thing" in
those algorithms.

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

so move(v[i]) must also erase the element and then move
the rest of the vector one place back?

| 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 sounds ok. I belive Kevlin Henney has one in "Clone Alone".

| 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,

sounds expensive to me.

| or copying entire containers.

a different thing...probably what we want.

Thanks for your comments, Howard.

Thorsten