Re: [boost] lifetime of ranges vs. iterators

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-08-30 01:12:32

On Sat, Aug 30, 2008 at 1:51 AM, David Abrahams <dave_at_[hidden]> wrote:
>
> on Fri Aug 29 2008, "Giovanni Piero Deretta" <gpderetta-AT-gmail.com> wrote:
>
>> On Fri, Aug 29, 2008 at 4:48 PM, David Abrahams <dave_at_[hidden]> wrote:
>>>
>>> I've been trying to say that generic algorithms *can't* worry about
>>> the range lifetime; they have to assume that the iterators they're
>>> passed will not be invalidated before they're destroyed.
>>
>> I think that the OP is talking about a different problem: let say you
>> want to name the result of stacked applications of range adaptors:
>>
>> template<typename Range>
>> void my_algo(Range& r) {
>>   auto stacked_range = r | filtered(filter) | mapped(mapper);
>>   // use stacked_range
>> }
>>
>> This may lead iterator lifetime problems, not because r iterators may
>> be invalid, but because the iterators of the range returned by
>> filtered(...) may become invalid as that temporary has been
>> destructed. There are many solutions:
>>
>> The easiest is splitting apart the expression, but is ugly.
>>
>> Then you could use expression templates to make the whole pipe
>> expression return a range only at the end.
>>
>> Finally, both filtered and mapped could guarantee that the iterators
>> are not invalidated when the range is destructed, but that may prevent
>> some space optimizations (like storing the predicate inside the range
>> instead of the iterator)).
>
> Or you could write the representation of the range in such a way that it
> didn't contain an exact representation of the iterators.  When you
> assemble a range from two iterators, store the common information
> separately, and reassemble the complete iterators only when they are
> requested.  When adapting iterators you'd do the same
> deconstruction/re-construction.  You could tack on some runtime
> error-checking for good measure.
>

Hum, this would means that every range needs to know how to construct
and deconstruct iterators of other ranges, at least if it wants to
guarantee that the minimum space possible is used.

It seems a bit complex, and there would be a need to come up with some
non obvious protocol to do that (some sort of compile time
introspection on ranges).
Is it really worth it? Are you advocating it, or it was just another
solution to consider?

-- 
gpd