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

Subject: Re: [boost] [Range] Range adaptor approach for temporary range lifetime issue
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2012-06-29 07:37:22

On 28-06-2012 13:57, Dave Abrahams wrote:
>
> on Sun Jun 24 2012, "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung-AT-gmail.com> wrote:
>
>> 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?
>
> The lazy case is actually able to perform some "optimizations" like
> eliminating double-reverses.  It's not at all clear that these tricks
> would improve performance in reality, though.

Well, I think we would be going too far if we tried to do that in the 
library. There is a difference between optimizing common use-cases and,
ahem, strange uses.

That said, with some effort, it might be possible to join certain 
adaptors into one compound adaptor. For example

   range | transformed( &Trans ) | filtered( &When )

may become one iterator type, hence simplyfying the task for the compiler.

Also, I'm inclined to think "lazy" is best for other reasons: it allows 
the cpu to work on one iterator object at a time, instead of 
interleaving construction of the two iterators all the time.
I guess it would be a problem if the iterators are not cached, but 
recomputed; probably not a problem in practice.

-Thorsten