Re: [Boost-users] any_range vs. “canonical form” - what is the latter?

On Sat, Apr 9, 2011 at 7:36 PM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:

Den 09-04-2011 18:45, Neil Groves skrev:

On Sat, Apr 9, 2011 at 4:36 PM, Steven Watanabe

...

...

For example, copying the range into a vector.

Yes, this is exactly the alternative design that I had in mind when writing the documentation. The overhead of iterating over an any_range is quite considerable, and often compares poorly with copying a concrete result-type into a container such as a vector. However, this is not always the case and some of the users of Boost.Range have desired the ability to implement algorithms that operate upon any_range instances. This is sometimes desirable to allow, for example, exposure of algorithms from a shared library that supports various containers.

Two questions:

A. would it not be more efficient to store only a range object instead of two iterators as this leads to each iterator begin potentially heap-allocated. (e.g. use boost::iterator_range<I> internally)

This is worth investigating particularly for large iterators. I've found through profiling many applications that my current small-buffer optimization means that the iterators are allocated in an embedded buffer, so the iterators are typically allocated using placement new which compiles out to a no-op. Hence I think that the further optimization you have proposed would be limited to the unusual case of wrapping large iterators. It is still worth some brain cycles though. I'll look into this.

B. would it not make sense to remove a whole bunch of those template arguments to any_range? Why can't I just say

void foo( const any_range<int>& rng ) { switch( rng.category() ) { case boost::ranges::consequtive: ...; break; case boost::ranges::randome_access: ...; break; // etc } }

I didn't go this route because a user can decide to use the default arguments for the other template parameters and implement specialized algorithms as you have proposed. However, by allowing the optional use of the additional template parameter types, it allows full interoperability with algorithms not explicitly coded for use with any_range. I should probably give some thought to improved support for people wishing to code algorithms that use runtime detection of category etc. This could definitely be improved.

-Thorsten

Thanks for your ideas. Regards, Neil Groves