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 15:56:01

On 19 Feb 2014 20:22, "Eric Niebler" <eniebler_at_[hidden]> wrote:
>
> On 02/19/2014 10:54 AM, Ion Gaztañaga wrote:
> > El 18/02/2014 19:21, Adam Wulkiewicz escribió:
> >> I'll wait for the feedback from the rest of the community. Ion are you
> >> ok with this?
> >
> > A forward move iterator is very useful when inserting values in
> > containers. The forward property is used to know how many elements are
> > in the range. After that, each element is only moved once. I see no
> > problem with this approach.
>
> That's a very good example. Thanks. I need to think about whether that
> use case justifies the danger.
>

That isn't a compromise you need to make. I believe you are trying to
prevent cases of multiple moves where that is invalid. This doesn't and
shouldn't be done by piggybacking on traversal concepts. There are a number
of valid use cases that would be broken:
1. Distance before traversal. I have no concrete use cases of this one.
2. Reverse traversal. I have numerous examples of this in production.
3. Multipass traversal moving subsets of objects with each pass while
correctly avoiding multiple moves of an individual object. I have numerous
examples of this in production. In many cases one can refactor to a less
elegant single pass solution, however where I have state from initial
passes the refactoring would be very significant and make the code worse. I
would have to include additional copies or fork the move iterator.

I think the danger you highlight is real, but I think the problem is
erroneous moves and the solution of adding tracking and assertions for this
is much more comprehensive and direct in addressing the problem.

Please don't increase restrictions on the move iterator. I know I can fork
the old code but I cannot believe I will be the only person left with
broken code from this change.

> Eric
>

I am sorry if I have repated myself.  For my random access stride, sure it
only suffers an unnecessary performance penalty, but reverse is broken and
so are the other cases outlined above. Just having suboptimal striding was
enough to convince me since my applications are often very performance
oriented.

I hope I haven't annoyed anyone with my posts. I'm certainly trying not to.

Regards,
Neil Groves