On Mon, Sep 1, 2008 at 1:56 PM, Arno Schödl <aschoedl@think-cell.com> wrote:
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.
Hei, maybe this is all that we need! Let's have a metafunction that given an iterator type returns its preferred range type (the associated range). The default might be boost.range or even std::pair. The developer of an iterator adaptor, can specialize the metafunction so that the associate range is the optimum representation for an iterator pair.
Do you think this would be enough? It seems too simple to me, so probably I'm missing something...
I wouldn't know what to do when my iterator_adaptor needs three iterators to the >same range. I could store two efficiently as a range and retrieve them when needed >by querying range::begin()/end(), but what do I do with the third? Dave's factored terators go further in the same direction, basically dropping the requirement that the >common data must be a range, it can be anything.
You are right. It wouldn't work with three iterators. But three iterators are a range of ranges. Maybe segmented iterators (or, better, segmented ranges) can come to the rescue? Need to think about it. Could you give a practical example of an iterator adapter needing three iterators?
Both proposals have the disadvantage that I need to wrap/unwrap the [common data >(Dave)/range (Giovanni)] whenever I change one of the wrapped iterators. I'd rather >store the common data explicitly, and have indirections inside the iterators that point >to it.
You would still have to allow for storing the wrapped iterator in the wrapper if the wrapped iterator does not support refactoring. I do not think there is a way around it. Also, I have this (completely unfounded) feeling that an iterator that relies on accessing common data in the owning range might be harder to optimize. I think that ranges should be used for long term storage, so if the iterator size itself is not optimal shouldn't be a big problem. Storing all data in a range and using an indirection in the iterator would be beneficial when that data would make the iterator expensive to copy (for example the shared pointer in shared_container_iterator: you could move the shared pointer in a shared_container_range and put a plain pointer in the iterator itself). -- gpd