Eric Niebler 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
On 02/18/2014 09:16 AM, Adam Wulkiewicz wrote: that assume anything other than Input is pretty much guaranteed to make you very unhappy.
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.
Sure, this makes sense. At least if someone doesn't want to do something clever which I can't come up with at the moment ;). We could provide some #ifdef enabling the STD behavior, e.g. BOOST_MOVE_ITERATOR_USE_BASE_CONCEPT. And a #warning saying something meaningful if this is enabled ;). I'll wait for the feedback from the rest of the community. Ion are you ok with this? Regards, Adam