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

On 02/19/2014 12:56 PM, Neil Groves wrote:

On 19 Feb 2014 20:22, "Eric Niebler" 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