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

Subject: Re: [Boost-users] any_range vs. “canonical form” - what is the latter?
From: Neil Groves (neil_at_[hidden])
Date: 2011-04-09 16:19:14

On Sat, Apr 9, 2011 at 7:36 PM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> Den 09-04-2011 18:45, Neil Groves skrev:
>
>  On Sat, Apr 9, 2011 at 4:36 PM, Steven Watanabe <watanabesj_at_[hidden]
>>
>
>
>>    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