No move_if or move_n in C++0x?

[Scott Meyers]

Draft C++0x (N3000) makes no mention of the algorithms move_n or
move_if, although these do exist in copy versions (i.e., copy_n,
copy_if). The only discussion I could find for this lack of symmetry
is at http://www.cpptrak.info/ballotcomment/353 , where a mild
argument is made against move_if, but not move_n.

Is there any additional light to be shed on the reasons for the
absence of move_n and move_if from draft C++0x?

Thanks,

Scott

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[Johannes Schaub (litb)]

Scott Meyers wrote:

> Draft C++0x (N3000) makes no mention of the algorithms move_n or
> move_if, although these do exist in copy versions (i.e., copy_n,
> copy_if). The only discussion I could find for this lack of symmetry
> is at http://www.cpptrak.info/ballotcomment/353 , where a mild
> argument is made against move_if, but not move_n.
>
> Is there any additional light to be shed on the reasons for the
> absence of move_n and move_if from draft C++0x?
>

I was in the impression that we could use copy_if(make_move_iterator(a),
make_move_iterator(b), d, p); and the-like for this. I'm wondering whether
that would work?

[Howard Hinnant]

On Dec 7, 2:02 am, Scott Meyers <NeverR...@aristeia.com> wrote:
> Draft C++0x (N3000) makes no mention of the algorithms move_n or
> move_if, although these do exist in copy versions (i.e., copy_n,
> copy_if). The only discussion I could find for this lack of symmetry

> is athttp://www.cpptrak.info/ballotcomment/353, where a mild

> argument is made against move_if, but not move_n.
>
> Is there any additional light to be shed on the reasons for the
> absence of move_n and move_if from draft C++0x?

In the early move papers (N1717) it is recognized that there are
potentially many algorithms with copy-like semantics where a move-like
version would be useful:

replace_move
replace_move_if
remove_move
remove_move_if
unique_move
reverse_move
rotate_move
partition_move
partial_sort_move
...

However it was also desired not to double (or even greatly increase)
the number of algorithms just to supply a moving version. Therefore
an iterator adaptor was introduced which can change an algorithm from
copy-like behavior to move-like behavior: move_iterator.
move_iterator plays the same role as reverse_iterator in changing a
generic algorithm's behavior. E.g. you can "move_if" with:

copy_if(move_iterator<I>(f), move_iterator<I>(l), out);

N1717 also identified two move-adapted algorithms that might be used
so often, that move versions of them should be provided simply for
notational convenience:

* move(f, l, o) is equivalent to copy(move_iterator<I>(f),
move_iterator<I>(l), o).
* move_backward(f, l, o) is equivalent to copy_backward
(move_iterator<I>(f), move_iterator<I>(l), o).

-Howard