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 06:52:20

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 do not perceive a compensating 
advantage for this approach. Of course, I may well be missing the 
advantage and invite correction.

> But, in some range adaptors, adapting the underlying iterators
> is a bit expensive. For example
> * In filtered_range, adapting the begin iterator can be expensive,
> since it needs to advance the begin iterator to the first "unfiltered"
> iterator.
> * In oven's dropped_range (this ignores the first n elements in the range)
> on bidirectional range, adapting the begin iterator takes O(n) time.
>
> So your range adaptors are inefficient in these cases.
> (moved_range internally caches the adapted iterators to avoid
> this problem.)

Exactly so. FWIW I like the proposed solution but strongly prefer the 
explicit move. My reasoning is that I prefer to apply the zero overhead 
principle, and that historically choosing implicit has been associated 
with more design errors. Implicit moving while superficially appealing 
doesn't seem like a good idea intuitively to me.

I am, of course, assuming that there isn't a zero-cost implicit move 
solution that is completely general.

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

Neil Groves