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: Eric Niebler (eniebler_at_[hidden])
Date: 2014-02-19 18:18:32

On 02/19/2014 12:56 PM, Neil Groves wrote:
> 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.

std::vector's constructor does distance before traversal for forward
iterators so it can pre-allocate the memory.. It's a legitimate use case.

> 2. Reverse traversal. I have numerous examples of this in production.

Can't you reverse *then* move?

> 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.

Can you describe your usage scenario? I'm having a hard time imagining one.

> 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.

No, I won't change it. I think Ion convinced me.

> 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 don't understand why you think my suggestion would make a stride
adaptor any less efficient. Naturally, there would have to be a
specialization for random-access. Striding an input range yields an
input range. Striding a forward range yields a forward range. Likewise
for bidirectional and random-access. I've done it. It's possible. And
there's no performance penalty that I can see.

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

Of course not! This is a technical discussion. I'm not taking anything
personally.

Eric