Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk