"Howard Hinnant" <hinnant@twcny.rr.com> wrote in message news:83B293FA-1013-11D9-9D49-003065D18932@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