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

Subject: Re: [boost] [move] [range] move algorithm (was: interest: the pass-by-value...)
From: Neil Groves (neil_at_[hidden])
Date: 2014-02-19 06:01:57

On Wed, Feb 19, 2014 at 1:51 AM, Eric Niebler <eniebler_at_[hidden]> wrote:

> On 02/18/2014 10:30 AM, Neil Groves wrote:
> > On Tue, Feb 18, 2014 at 5:32 PM, Eric Niebler <eniebler_at_[hidden]>
> 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
> 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/stride.hpp
>
> 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