Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-10-02 08:04:59

On Oct 2, 2004, at 8:04 AM, Thorsten Ottosen wrote:

> "Howard Hinnant" <hinnant_at_[hidden]> wrote in message
> | 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()),

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.


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