RE: [boost] Re: Most needed/desired features in C++

From: Michiel Salters (Michiel.Salters_at_[hidden])
Date: 2002-02-21 10:56:10

Valid points. I think your point about carrying around the begin
iterator is valid; but this was a quick sketch. I can imagine
making the at_end( ) functionality separable from the
begin part ( i.e. have at_end( ) in a base class, the begin
iterator in the derived Range class, and use a slicing copy)

Let me state my point somewhat clearer :If the end should
always be an iterator, you can end up with additional baggage
in such iterators. By allowing a different type to represent the
end, all valid iterators in such ranges can be smaller.

Perhaps we should name it std::end<ITERATOR>:

template < typename ITERATOR >
void foo( ITERATOR i, 
             std::end<ITERATOR> TheEnd =  std::end<ITERATOR>( ) )
{
  for ( ;i != TheEnd ; ++i )
    bar( *i ) 
}

int array[10];
end<int*> TheEnd = array+10;

foo( array, TheEnd );

istream_iterator<int> ( file ) FileIter;
foo ( FileIter );

Insert code for operator==( Iter, end<Iter> ) as appropriate :)

-- 
Michiel Salters
> -----Original Message-----
> From: David Abrahams [mailto:david.abrahams_at_[hidden]]
> Sent: donderdag 21 februari 2002 16:41
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Most needed/desired features in C++
> 
> 
> 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.
> 
> 
> 
> Info: http://www.boost.org  Send unsubscribe requests to: 
<mailto:boost-unsubscribe_at_[hidden]> 
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/