Re: [boost] Re: Loki SmartPtr study: Policy orthogonality issues

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-11 15:55:03

----- Original Message -----
From: "rogeeff" <rogeeff_at_[hidden]>

> > Any generic class designed to operate on iterator ranges can be
> instantiated
> > with these shared_array jobbies instead; the storage will be
> reclaimed as
> > soon as the program is done with it.
>
> Look, even you talking about *iterator*. Not shared_array, but
> iterator implemented in terms of shared_array.

...because a shared_array with pointer arithmetic models
RandomAccessIterator as well as SmartArrayPointer.

I suppose you're suggesting that we use iterator_adaptor over shared_array
to get that functionality. That should work optimally, if the shared_array
can be configured to use a single pointer to a count, which points to the
base:

template <class SharedArray>
struct shared_array_iterator_policies
    : default_iterator_policies
{
    shared_array_iterator_policies() {}
    shared_array_iterator_policies(SharedArray a) : m_ownership(a) {}
private:
    SharedArray m_ownership;
};

template <class SharedArray>
struct shared_array_iterator_generator
{
    typedef iterator_adaptor<
        typename SharedArray::pointer
        , shared_array_iterator_policies<SharedArray>
    > type;
};

typename shared_array_iterator_generator<SharedArray>::type
make_shared_array_iterator(SharedArray const& x)
{
    typename shared_array_iterator_generator<SharedArray>::type result_t;
    return result_t(x.get(), x);
}

> I am sure you could design your solution with owning iterators. The
> question is though, does this logic belong to smart_ptr?

Good question. It depends whether users see this on a continuum with their
other smart pointers. Maybe this is where an IDL comes in handy. Then a
uniform interface can select the adapted shared_array_iterator when that's
what people ask for.

-Dave