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
Well... This was to allow easy manual loops.
I have doubts about how well this "range/iterator" concept maps onto bidirectional and random access. That said...
It maps ok with bidirectional/random access. If an iterator has a given iterator category, the range will preserve it. I have used it in code, and it's quite powerful.
...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.
Indeed ;)
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.
As you probably know, the library is around 1 year old. I've used it heavily on some of my projects, and all I can say is that iteration capability has helped me much. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html