Re: [boost] [move] [range] move algorithm (was: interest: the pass-by-value...)

On Wed, Feb 19, 2014 at 1:51 AM, Eric Niebler wrote:

...

On Tue, Feb 18, 2014 at 5:32 PM, Eric Niebler wrote:

...

On 02/18/2014 09:16 AM, Adam Wulkiewicz wrote:

...

Hi Eric,

I agree that many scenarios would end in much unhappiness! I disagree

On 02/18/2014 10:30 AM, Neil Groves wrote: that

...

unhappiness is pretty much guaranteed. I believe there are valid scenarios that would be broken by increasing the requirements to demand single-pass traversal. The most common case that I think would be broken in my own code is where I am using a random-access iterator to stride.

Why in the world does a stride iterator need to be random-access? Here is a strided range adaptor that works with input iterators:

https://github.com/ericniebler/range-v3/blob/master/include/range/v3/view/st...

It's not even hard.

I understand fully that a stride can be implemented with a single-pass traversal, but this is not optimal for striding by large values as I'm sure you know. Why should combining with move make my stride less efficient? I am, of course, only using this as an example. I think there are many cases where we use the random-access traversal and dereference a subset of the elements of the underlying range. It is then valid to pass over the source range again starting from another point and stride, or do a number of other operations. This is before we allow well-defined semantics for multiple moves, which I believe is also valid.

Eric

Neil Groves