replace_copy and replace_copy_if

Discussion in 'C++' started by Fraser Ross, Sep 30, 2006.

  1. Fraser Ross

    Fraser Ross Guest

    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.



    Posted Via Usenet.com Premium Usenet Newsgroup Services
    ----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    ----------------------------------------------------------
    http://www.usenet.com
     
    Fraser Ross, Sep 30, 2006
    #1
    1. Advertising

  2. Fraser Ross

    Kai-Uwe Bux Guest

    "Fraser Ross" <fraserATmembers.v21.co.uk> wrote:

    > 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
     
    Kai-Uwe Bux, Sep 30, 2006
    #2
    1. Advertising

  3. Fraser Ross

    Fraser Ross Guest

    > 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.



    Posted Via Usenet.com Premium Usenet Newsgroup Services
    ----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    ----------------------------------------------------------
    http://www.usenet.com
     
    Fraser Ross, Oct 1, 2006
    #3
  4. Fraser Ross

    Kai-Uwe Bux Guest

    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" <fraserATmembers.v21.co.uk> wrote:
    >> 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.


    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
     
    Kai-Uwe Bux, Oct 1, 2006
    #4
  5. Fraser Ross

    Fraser Ross Guest

    "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.



    Posted Via Usenet.com Premium Usenet Newsgroup Services
    ----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    ----------------------------------------------------------
    http://www.usenet.com
     
    Fraser Ross, Oct 1, 2006
    #5
  6. Fraser Ross

    Kai-Uwe Bux Guest

    "Fraser Ross" <fraserATmembers.v21.co.uk> wrote:

    >
    > "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
     
    Kai-Uwe Bux, Oct 1, 2006
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nut Cracker
    Replies:
    1
    Views:
    353
  2. jakk
    Replies:
    4
    Views:
    12,496
  3. Tim Meagher
    Replies:
    8
    Views:
    1,307
    Karl Seguin
    Jun 18, 2005
  4. Jerry Manner
    Replies:
    2
    Views:
    6,611
    SpaceGirl
    May 30, 2005
  5. titi

    if and and vs if and,and

    titi, Mar 9, 2007, in forum: VHDL
    Replies:
    4
    Views:
    613
    Mike Treseler
    Mar 11, 2007
Loading...

Share This Page