Re: lifetime of ranges vs. iterators

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost