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 separation 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 example.
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