6 Jun
2013
6 Jun
'13
8:41 a.m.
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
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