|
Boost : |
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-08-29 20:09:46
On Sat, Aug 30, 2008 at 1:51 AM, David Abrahams <dave_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk