Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-11-10 08:11:10

Richard Peters <r.a.peters <at>> writes:

> "Robert Ramey" <ramey <at>> wrote in message
> news:cmrl55$hng$1 <at>
> >
> > I agree that iterators aren't that easy or intuitive to work with. So our
> > motivations have much in common. My view is that iterators can be made
> > easier to work with without changing their fundamental character and
> > without
> > the need to introduce what I see as a new concept (ranges) that is "almost
> > the same" as an existing concept - pair of iterators.

Like Robert I am uncomfortable with a
range concept that has iteration capabilities.
For one thing, standard containers don't
satisfy that concept, and it seems to me
that a container ought to be a range without
any special adaptation. Furthermore
I have doubts about how well this "range/iterator"
concept maps onto bidirectional
and random access. That said...
> While iterators are very good at what they do -- provide access to elements
> in a sequence -- they do not capture the concept of a sequence very well. If
> I want to access a sequence of elements, I'd like to see a clean front-end,
> and I believe that John's range library can provide me with such a clean
> front-end. Using for_each(s.begin(), s.end(), ...) is too low-level, it
> exposes details of a sequence that I do not want to know. I do not want to
> for_each on a begin and an end, I want to for_each on a sequence:
> for_each(s, ...). It's a conceptual layer, admittedly a small one, but it
> provides a great front-end for the back-end of iterators.

...I agree with Richard that iterators are often at the wrong level
of abstraction, and...

> For me, the following example from the Range Adaptors and Composition(s)
> documentation illustrates that:
> // [1] print all even elements (not using range adaptors)
> typedef boost::filter_iterator<array> filter_iterator;
> rng::for_each( irange<filter_iterator>(
> filter_iterator(some_array.begin(), is_even),
> filter_iterator( some_array.end(), is_even), print );
> // [2] print all even elements (using range adaptors)
> rng::for_each( filtered(some_array, is_even), print);

...Perhaps more importantly, iterator interfaces don't lend themselves
to functional composition:

         transformed(filtered(some_array, is_even), _1 / 2)
       , print);

Try to say *that* with iterators.

This is the design approach taken in
MPL and Fusion, and it works very well. I am
strongly for an algorithm and lazy adapter
library based on ranges, and moderately
strongly against directly giving ranges any
direct iteration capability.

Dave Abrahams
Boost Consulting

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