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.
> 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:
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk