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-28 15:01:32

> Range forwarders (e.g. uniqued, taken(1), strided(1), etc.) are generally
> lightweight, and so the lazy implementation should also be lightweight.
> 
> As for moved_range, avoiding caching adapted ranges greatly reduces
> its size. Indeed, whether or not caching adapted ranges was one of my
> major concerns in implementing moved_range.
> moved_range stores a moved container and a fusion vector of
> range forwarders. Without caching an adapted range,
> the container have to be adapted each time begin or end is called.
> This means that a single pair of begin/end calls requires adapting
> two pairs of begin/end iterators. This seems inefficient, and so I chose to
> cache an adapted range in moved_range.
> 
> However, I cannot predict how badly this size problem affects
> the performance, because my knowledge about copy elision is scarce…
> 
This is typically low cost since the typical use-case is to call into a template range-based algorithm, hence the entire calling context is known allowing the compiler to optimise well.

There are strange conditions such as | reversed | reversed that could be optimised. I wonder if anyone would do something like this?

It is, as you are probably aware, much more important to keep iterators small than it is to keep the Range small. The iterator can and does make enormous difference to performance.

If we can make ranges smaller without making iterators larger then we should do so as long as it is not excessively complicated. I'd be happy to make improvements in this manner.

> 
> Regards,
> Michel
> 

Thanks for you help.

Regards,
Neil Groves