replace_copy and replace_copy_if

F

Fraser Ross

Is the resultant range copied to not necessarily in the order of the
input range? I only have access to the 97 draft standard which doesn't
mention stability. The remove algorithm versions I know are stable but
I'm not sure about the replace algorithm versions.

Fraser.
 
K

Kai-Uwe Bux

Fraser Ross said:
Is the resultant range copied to not necessarily in the order of the
input range? I only have access to the 97 draft standard which doesn't
mention stability. The remove algorithm versions I know are stable but
I'm not sure about the replace algorithm versions.


[25.2.4/3-5]

template<class InputIterator, class OutputIterator, class T>
OutputIterator
replace_copy(InputIterator first, InputIterator last,
OutputIterator result, const T& old_value, const T& new_value);

template<class Iterator, class OutputIterator, class Predicate, class T>
OutputIterator
replace_copy_if(Iterator first, Iterator last,
OutputIterator result, Predicate pred, const T& new_value);

4 Requires: Type T is Assignable (23.1) (and, for replace_copy(),
EqualityComparable (20.1.1). The ranges [first, last) and [result, result +
(last - first)) shall not overlap.

5 Effects: Assigns to every iterator i in the range [result, result +
(last - first)) either new_value or *(first + (i - result)) depending on
whether the following corresponding conditions hold: *(first + (i -
result)) == old_value, pred(*(first + (i - result))) != false.


The way I read this is that the elements are processed in order.


Best

Kai-Uwe Bux
 
F

Fraser Ross

The way I read this is that the elements are processed in order.

The order of invocation and doing a stable copy are not the same thing.
I would expect the intention is to do a stable copy. It should be
stated as it is with the remove algorithms. unique_copy is probably
another that should state a stable copy is done.

Fraser.
 
K

Kai-Uwe Bux

Please quote enough material for your post to stand alone. Here is again the
quote from the standard:


[25.2.4/3-5]

template<class InputIterator, class OutputIterator, class T>
OutputIterator
replace_copy(InputIterator first, InputIterator last,
OutputIterator result, const T& old_value, const T& new_value);

template<class Iterator, class OutputIterator, class Predicate, class T>
OutputIterator
replace_copy_if(Iterator first, Iterator last,
OutputIterator result, Predicate pred, const T& new_value);

4 Requires: Type T is Assignable (23.1) (and, for replace_copy(),
EqualityComparable (20.1.1). The ranges [first, last) and [result, result +
(last - first)) shall not overlap.

5 Effects: Assigns to every iterator i in the range [result, result +
(last - first)) either new_value or *(first + (i - result)) depending on
whether the following corresponding conditions hold: *(first + (i -
result)) == old_value, pred(*(first + (i - result))) != false.

Fraser Ross said:
The order of invocation and doing a stable copy are not the same thing.
I would expect the intention is to do a stable copy. It should be
stated as it is with the remove algorithms. unique_copy is probably
another that should state a stable copy is done.

The standard does not talk about "order of invocation" at all. It sets which
OutputIterator gets assigned which value: the OutputIterator result+n,
i.e., n slots past result is assigned the value from the InputIterator
from+n or the value new_value depending on the result of the test. This
only specifies the order in which the items will occur in the output
sequence but it does not specify the order in which the necessary
assignments are carried out. In other words, this spells out that the copy
is stable but does not specify the order of any invocations. For example,
if both iterators are bidirectional, the process could go backwards, but
the resulting output sequence is still uniquely determined by the
positional requirements set out in the Effects section.


However, maybe, I misunderstand what you mean.


Best

Kai-Uwe Bux
 
F

Fraser Ross

"Kai-Uwe Bux"
The standard does not talk about "order of invocation" at all.
It does. For for_each there is this:
Effects:
Applies f to the result of dereferencing every iterator in the range
[first, last), starting from first and proceeding to last - 1.
Also it is stated for the <numerics> algorithms and copy/copy_backward.


I see now the copying has to be stable from the description. Most of
what you said I already knew.


Fraser.
 
K

Kai-Uwe Bux

Fraser Ross said:
"Kai-Uwe Bux"
The standard does not talk about "order of invocation" at all.
It does. For for_each there is this:
Effects:
Applies f to the result of dereferencing every iterator in the range
[first, last), starting from first and proceeding to last - 1.
Also it is stated for the <numerics> algorithms and copy/copy_backward.

Your snipping is really annoying: what you quote is the topic sentence of a
paragraph where I specifically discuss the Effects section of replace_copy
and replace_copy_if. I never intended to make a statement whose scope goes
beyond the particular section under discussion and had you quoted enough,
it would show. Please use a quoting style that avoids making others look
like complete idiots.

[snip]



Best

Kai-Uwe Bux
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top