Re: [boost] lifetime of ranges vs. iterators

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-01 09:31:29

On Mon, Sep 1, 2008 at 1:56 PM, Arno Schödl <aschoedl_at_[hidden]> 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