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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk