Boost logo

Boost :

Subject: Re: [boost] lifetime of ranges vs. iterators
From: Arno Schödl (aschoedl_at_[hidden])
Date: 2008-09-07 06:02:18

>> > increment() {
>> > for( difference_type i=0; i<N && !base.empty(); ++i ) {
>> > base.increment(); // the adapted_range::increment which increments begin,
>> > base is a range
>> > }
>> > }
>> I don't think you're fully appreciating what a huge impact such a
>> complex implementation of increment() would have on performance.
> Sorry, I meant this as the implementation for forward range. You don't want to
> use increment for random_access ranges, obviously.

>I don't see what the traversal category has to do with anything.

A strided_iterator should use advance on random_access_ranges rather than increment.

> Thinking about it some more, I believe the associated_range abstraction is not
> quite the right one yet. It works for forward_ranges, which is why I did not
> notice earlier, but not for bidirectional and random_access_ranges.
> > The correct abstration is bounded_iterator, which is an iterator + the knowledge
> > of whatever bounds it needs.

> Only if you don't care about eliminating other redundancies.

What are your referring to specificly? If you are referring to storing the predicate or stride length, this is taken care of because the iterator adaptor stack stores this information only once:

template<I, F>
struct bounded_iterator< filter_iterator<I,F> > {
   typedef filter_iterator<I,F> type;

template<I, F>
struct filter_iterator {
   typename bounded_iterator< I >::type m_base;
   F m_f;


Ranges would store their base ranges rather than a pair of iterators, and generate iterators on demand, so they store predicate/stride_length/... only once as well.


Dr. Arno Schoedl · aschoedl_at_[hidden] 
Technical Director 
think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

Boost list run by bdawes at, gregod at, cpdaniel at, john at