On Tue, Feb 18, 2014 at 5:32 PM, Eric Niebler
On 02/18/2014 09:16 AM, Adam Wulkiewicz wrote:
Hi Eric,
Eric Niebler wrote:
On 02/15/2014 02:17 PM, Adam Wulkiewicz wrote:
There is already boost::move_iterator in Boost.Move Please make sure that move iterators and ranges are Input and not anything else, regardless of what the standard says. The standard is dangerously wrong in this regard.
Thanks for the advice. It's because the user might by mistake go through some elements more than once which would result in some number of moves from the same element or do you have something more surprising in mind?
That's it precisely. And using move iterators in standard algorithms that assume anything other than Input is pretty much guaranteed to make you very unhappy.
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. Currently I can stride and move ever n-th element. Isn't this perfectly acceptable? I'm not convinced we should break any valid use-cases to detect more errors. Perhaps we can find a better mechanism to detect double moves in debug builds instead?
Unfortunately the boost::move_iterator follows the standard here. And since it's already in Boost it probably shouldn't be changed to ensure backward compatibility. We could of course implement different one and use it in Boost.Range but I'm not sure if this is a good idea. Should we have two different move_iterators in Boost?
I take a hard stand on this. A Forward move iterator is totally broken. I have *no* sympathy for people who are using move iterators where Forward is needed. Their code is buggy. We should change boost::move_iterator and help people find their bugs. I have zero compunction about doing this.
If my previous paragraph is correct I believe we should not break working user code. Under my current understanding I don't think multiple (and therefore invalid) moves should be prevented by increasing the limits of the traversal. I think that the problem is a multiple moves and this can and should be dealt with directly instead. I wonder if the standard is liberal in the traversal requirements for similar reasons?
Eric
I'm conscious that I could easily be misunderstanding some information and therefore my chain of reasoning may be broken. Neil Groves