Subject: Re: [boost] [move] [range] move algorithm (was: interest: the pass-by-value...)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-02-18 13:21:16
Eric Niebler wrote:
> 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.
>
>> 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