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