From: David Abrahams (dave_at_[hidden])
Date: 2008-08-31 23:24:44
on Sun Aug 31 2008, Arno SchÃ¶dl <aschoedl-AT-think-cell.com> wrote:
>> > How is the separation of common_data and unique_data different from a
>> > of ranges and iterators? If iterators of ranges can rely on their range to
>> > exist, this is where common data like functors, end iterators etc. can be
>> > stored.
>> Naturally the point is to store the common data once when you need to
>> store more than one iterator to the same sequence -- in a range, for
>> If you're asking why I bother reconstituting the whole iterator out of
>> its parts, instead of simply referring to the common_data stored in the
>> range: an adapted iterator is a useful concept regardless of whether
>> anyone is using a range abstraction.
> You could provide an adapted_iterator and also an adapted_range.
My point is that the adapted_range would then have semantically
equivalent iterators with a different representation (and an extra
indirection), which seems like a waste.
> If we subscribe to the rule that ranges must stay valid for their
> iterators to be valid,
I don't. I do subscribe to the rule that generic code cannot afford to
destroy an arbitrary range while its iterators are still in use.
> the adapted_range::iterator can use the common data stored in the
> range, while the adapted_iterator stores the common data itself. Both
> could even be derived from the same source code.
Yeah, that's still a lot of coding effort.
> Do you then still need a factored iterator?
You need to be able to take two adapted iterators and turn them into a
range. Do you want that range to contain redundant data? I don't.
> Or do you want to avoid people having to use the range abstraction?
I certainly don't want to force it on them.
> If you pass iterator pairs to algorithms instead of ranges, at least
> this parameter passing would have to pass the common data redundantly,
> even if inside the algorithm, say when many iterators have to be
> stored, the common data is stripped and stored separately.
Of course that's understood.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk