Re: lifetime of ranges vs. iterators

For iterators, the make_ helpers are great:

vector<int> vecnA;
vector<int> vecnB;

DoSomethingWithRangeThatStoresIterators( 
	make_difference_iterator( vecnA.begin(), vecnA,end(), vecnB.begin(), vecnB.end() ),
	make_difference_iterator( vecnA.end(), vecnA,end(), vecnB.end(), vecnB.end() )
);

The equivalent with ranges, supposedly easier, would now look like this:

vector<int> vecnA;
vector<int> vecnB;

difference_range< int, int > diffrng( vecnA, vecnB ); // watch out with scope
DoSomethingWithRangeThatStoresIterators( diffrng ); 

as opposed to the much nicer:

vector<int> vecnA;
vector<int> vecnB;

DoSomethingWithRangeThatStoresIterators( make_difference_iterator( vecnA, vecnB ) );

If we drive this stacking to one or more levels, things pretty quickly become pretty ugly. Do we really want that?

Arno

-----Original Message-----
From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at> lists.boost.org] On Behalf Of David Abrahams
Sent: Friday, August 29, 2008 1:01 PM
To: boost <at> lists.boost.org
Subject: Re: [boost] lifetime of ranges vs. iterators

on Fri Aug 29 2008, Arno Schödl <aschoedl-AT-think-cell.com> wrote:

> Hello,
>
>  
>
> some adaptor ranges need certain constant information about their
> underlying ranges. For example, iterating over a forward
> "difference_range", the difference between two sorted ranges, requires
> access to the ends of the underlying ranges. These two additional
> iterators are constant, they do not change when the
> difference_iterator is incremented.
>
>  
>
> Now, where should this additional constant information be stored?
>
>  
>
> a) In the difference_range, and each iterator holds a reference to the
> difference_range? That requires the difference_range to be alive as
> long as its iterators are alive. This may be difficult to ensure if
> the difference_range is a temporary.
>
> b) In the iterators, so the lifetime of adaptor iterators is
> independent of the adaptor range. Of course, one can use shared_ptrs
> and so on, but still the iterators are ultimately responsible to keep
> that information available.
>
> This initially seemed more natural to me, but if implemented naively
> by storing the additional iterators in the iterator itself, it leads
> to storage bloat: each difference_iterator needs 4 instead of 2 of its
> underlying iterators. When stacking difference iterators, the
> difference in required storage grows exponentially: instead of 2^N,
> you need 4^N storage...
>
> I feel that in order to solidify the range concept, one needs to make
> a choice whether a) or b) is "standard", because any user of ranges
> would need to know. Any thoughts on this?

Aren't standard containers supposed to satisfy the Range concepts?  When
the container is destroyed, its iterators are invalidated, right?

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

--
Dr. Arno Schoedl · aschoedl <at> think-cell.com 
Technical Director 

think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany 
http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost