Re: [boost] boost.range bug in transformed or sliced

Subject: Re: [boost] boost.range bug in transformed or sliced
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-06-06 04:41:17

On 06-06-2013 10:22, John Reid wrote:
> Suppose you wish to transform and slice a random access range.
> Surprisingly the order in which you apply the operations makes a big
> difference to performance. I'm guessing this is not desired behaviour,
> correct me if I'm wrong.

[snip]

> On an unrelated note the documentation for transformed does not mention
> that the function is part of the range return type. It is given as:
> boost::transformed_range<typeof(rng)>

A defect.

>
> Code to demonstrate the transform then slice problem:
>

I'm puzzled too. I can understand that filter_iterators needs to be
bidirectional. sliced should not compile if it is not given random 
access. So it must be something else.

-Thorsten