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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-12 00:28:08

----- Original Message -----
From: "joel de guzman" <djowel_at_[hidden]>
> ----- Original Message -----
> From: "David Abrahams" :
> > ----- Original Message -----
> > From: "joel de guzman" <djowel_at_[hidden]>
> >
> > >
> > > I think the problem is that C incorrectly combined the notion of
> > > pointers and iterators (and even arrays) in one whole uncanny mix.
> > > Are we trying to commit the same mistake again?
> >
> > Too late: RandomAccessIterator already requires operator[]. At no small
> > cost, BTW: see the iterator_adaptors library docs for a discussion of
the
> > limitiations!
>
> So why propagate the mistake? Why do we need a smart-pointer
> with iterator/array semantics when we have iterators and containers.
> Vector not efficient enough? Why not just use a small and fast buffer
> class with array semantics and the efficiency of fixed C malloced
> arrays? Popular demand does not justify another mistake.

Just to be clear here: I think it's a GOOD THING overall that pointers are
iterators.

I don't, however, think that array access integrates well with generalized
random acess iterators because you either have to restrict their power or
return a value from operator[] in some cases (which is what the standard
does). Since operator[] is basically redundant anyway (you can always use
*(p + n)), I'd prefer if it were left out of the requirements for random
access iterator rather than forcing a surprisingly suboptimal
implementation. I wouldn't want to just require a reference return from op[]
because that would rule out many useful iterators (e.g. counting_iterator).

Do we need a storage-owning random-access iterator? I don't, today. Somebody
probably does: it provides value beyond separated iterators and storage
ownership. Does it have to be in boost? Probably not. I showed how to put
one together on top of a shared array with iterator adaptors in just a few
lines of code. I think if we provide an easy way to build a solution it's
probably enough.

-Dave