[boost] Re: Boost Iterable Range Library update (v1.5)

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

Richard Peters <r.a.peters <at> student.tue.nl> writes:

> 
> "Robert Ramey" <ramey <at> rrsd.com> wrote in message
> news:cmrl55$hng$1 <at> sea.gmane.org...
> >
> > 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:

   ranges::for_each(
         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
http://www.boost-consulting.com