Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-21 10:41:02


You left out any mention that at_end was a member function from your
previous description. I naturally assumed it was a free function. As such, I
object: it forces me to carry around a range or container object in addition
to an end iterator to handle common cases. At the very least, that's clumsy.
It might also be inefficient.

----- Original Message -----
From: "Michiel Salters" <Michiel.Salters_at_[hidden]>

> > -----Original Message-----
> > From: David Abrahams [mailto:david.abrahams_at_[hidden]]

> > ----- Original Message -----
> > From: "Michiel Salters" <Michiel.Salters_at_[hidden]>
> >
> > > Is there a reason you want to have an end iterator, instead of an
> > > at_end( iterator ) function ? Implementing the latter in
> > terms of the
> > > former is trivial, but all you have is the at_end( )
> > functionality, you
> > > need a special singular iterator to signal at_end( ), which can make
> > > all iterators bigger. Furthermore, for many output
> > iterators, at_end( )
> > > is trivially implemented as "return false;". The corresponding
> > > iterator is much more work.
> >
> > I can think of several huge problems with at_end():
> >
> > * How do you iterate over a subrange?
> > * Is a pointer still an iterator? How do you write at_end()
> > for pointers?
> >
> > -Dave
>
> Seems simple to me:
>
> template < typename ITERATOR >
> class SubRange {
> ITERATOR b,e;
> public:
> SubRange ( ITERATOR b, ITERATOR e );
> bool at_end( ITERATOR i ) { return i==e; }
> };
>
> templae < typename T >
> class PtrRange : public SubRange<T*>
> {
> // Perhaps some special-purpose ctors?
> }
>
> My point was that if you have any end iterator, at_end( ) is trivial.
> The other way around is much harder - you often need an extra
> data member to create a singular iterator for the end condition.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk