On Sat, Aug 30, 2008 at 1:51 AM, David Abrahams <dave@boostpro.com> wrote:
I'm not sure this is as revolutionary as you think. Every other
language I've looked at has a get_next()/at_end() iterator abstraction, which is a lot like what you're proposing. My advice: make sure you keep in mind the whole problem domain. You can't understand the reason that C++ iterators are unlike those in other languages without looking at the algorithms.
BTW, ranges are equivalent to GoF iterators:
Well, they're informationally equivalent...
you just spell 'at_end' as 'empty(r)'; 'next()' as 'r = range(next(begin(r)), end(r))' (equivalently: 'r = rest(r))'; and '.get()' as '*begin(r)';
...but that is so ugly as to make them non-equivalent abstractions in my book. And that's a good thing for ranges ;-)
when I need a simple for loop (and can't reach for BOOST_FOREACH), the syntax I sometimes use is: for(range<container> r (c); r; r = rest(r)) { .... } Which isn't that bad. You could even write the increment as ++r.
The nice thing about ranges is that you can take them apart into their iterator components when you need the extra flexibility.
IMO ranges will be good for describing transformations at a high level, but algorithms, for the most part will, need that flexibility.
I have had the same experience, so agree 200%. -- gpd