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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2002-01-12 17:02:12

From: "David Abrahams" <david.abrahams_at_[hidden]>
> 
> > 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.
> 
> 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.

I agree that it is a useful idea, but am nervous about adding it directly
to the *_array classes.  I see these classes a just low level buffers, with
simple, minimal functionality. Since you can always get a pointer out of them
on which to do arithmetic I don't see a need for more.

I would be amenable to making our array classes fulfill the container
reqirements, in which case begin() might return the kind of iterator you
want.

But I'd be much more comfortable with an adaptor, or family of adaptors,
that provide richer sets of operations on top of any array-like container.