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