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