Re: [boost] lifetime of ranges vs. iterators

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-01 06:50:35

On Mon, Sep 1, 2008 at 5:24 AM, David Abrahams <dave_at_[hidden]> wrote:
>
> 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.

hum, which indirection?

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

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

-- 
gpd