Re: lifetime of ranges vs. iterators

On Sat, Aug 30, 2008 at 1:51 AM, David Abrahams <dave <at> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost