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