Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue

Subject: Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue
From: Neil Groves (neil_at_[hidden])
Date: 2012-06-24 18:14:11

On 24 Jun 2012, at 19:33, Jeffrey Lee Hellrung, Jr. wrote:

> On Sun, Jun 24, 2012 at 3:52 AM, Neil Groves <neil_at_[hidden]>wrote:
> 
>> On 24/06/12 10:51, Michel Morin wrote:
>> 
>> Now I'm curious: what are the advantages and disadvantages of implementing
>>>> reverse_range<R> as a pair of reverse_iterator< R::iterator >'s (I'm
>>>> being
>>>> sloppy here, but based on your above assertion, this is the present
>>>> implementation) versus as a wrapper around an R (held by reference or
>>>> value) directly? In the latter case, for example, reverse_range<R>::begin
>>>> would return reverse_iterator< R::iterator >(boost::end(r)) (where r is
>>>> the
>>>> wrapped range of type R).
>>>> 
>>> Below, I say boost::begin(r) and boost::end(r) as the underlying
>>> iterators.
>>> 
>>> Your range adaptors are "lazy adaptors":
>>> * Pipe operators does not adapt the underlying iterators in effect.
>>> * The underlying iterators are adapted only when begin/end is called.
>>> And each time begin/end of your range adaptors is called,
>>> the underlying iterators needs to be adapted.
>>> 
>> 
>> As a general idiom the use of lazily adapting upon the invocation of
>> begin/end would mix two responsibilities. If one considers the
>> complications involved with managing functor and predicate state being
>> delayed until the invocation of begin/end it appears to be a considerably
>> more complex solution.
> 
> 
> I don't understand what you mean here. Surely adapted iterators must
> likewise manage "functor and predicate state"? Can you elaborate?
> 

Sure it is often the case that the predicate is held by an iterator. However users have been free to implement their own range adaptors and I have frequently held a predicate once in a range rather than twice in the iterators.

> I do not perceive a compensating advantage for this approach. Of course, I
>> may well be missing the advantage and invite correction.
>> 
> 
> As Michael points out, it helps solve the temporary lifetime issue in for
> loops...and I guess it allows one to return adapted ranges from functions?
> 

Yes, I don't dispute that this is part of a working solution. I had not realised that this was a fundamental part of the proposed solution. I think it is worth exploring alternative solutions since I think none of us are entirely happy with the total impact of the change. I'm hoping to reduce the overhead when one does not require the move and to reduce the impact upon valid client code that may repetitiously call begin()/end().

> And, ultimately, if there's ultimately just one call to begin/end on the
> final adapted range (the common case?), both the present implementation of
> the Boost.Range adaptors and a lazy implementation would go through the
> same sequence of iterator constructions, right?
> 

In the common case it does make a small difference, however in the worst-cases the impact could be very large on what is perfectly valid client code. This does mean I completely reject this solution, but it does motivate me to look for alternative solutions. The proposal is better than anything I have implemented or got a very clear idea on yet. I'll look at building a prototype in the next couple of days.

> - Jeff
> 

Thanks for your help,

Neil Groves

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