On Oct 2, 2004, at 8:04 AM, Thorsten Ottosen wrote:
"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:
| 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.
This brings up a question: how should these iterators cope with nulls as you intend sole_ptr<T> to allow? Afterall, if the iterator is indirected it needs to assume non-null values.
I would just say "client be aware". I.e. you can work directly with the container<sole_ptr<T>>, possibly with nulls, but if/when you want to send it to an algorithm that is going to dereference every element, you better have your nulls out: for_each(indirect_iterator(c.begin()), indirect_iterator(c.end()), do_something); The Smart Container library is working at a higher abstraction level than container<sole_ptr<T>>. The latter is just a container<T*> except that each pointer owns itself. Nothing more. Indeed, if we had container<sole_ptr<T>> today, you probably could have implemented the Smart Container library on top of that with a lot less effort. -Howard