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

Subject: Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-24 14:33:56

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?

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?

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?

- Jeff