Re: Loki SmartPtr study: Policy orthogonality issues

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-11 14:59:34

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> 
> > Why would anyone want pointer arithmetic for a shared_array? ;-)
> >
> > I can understand the motivation behind scoped_array (std::vector 
too
> > inefficient, presumably) - although I've never encountered a 
situation
> where
> > std::vector doesn't work adequately.
> >
> > But shared_array? Or going even further, a hybrid 
container/iterator
> > shared_array with pointer arithmetic? I find it hard to justify.
> 
> 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.

> 
> It's not that different from what's going on with an iterator over 
on-disk
> objects. Andy Koenig also has a similar useful example of an 
iterator over
> singly-linked list nodes which are reclaimed when they become 
unreachable.
> 
> -Dave

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

Gennadiy.