question about the stl erase-remove idiom

Discussion in 'C++' started by Nan Li, Nov 8, 2005.

  1. Nan Li

    Nan Li Guest

    Hello,
    I have seen people doing erase remove idiom like the following:

    ' vec.erase(remove_if(vec.begin(), vec.end(), is_odd<int>),
    vec.end() );'

    I remember Scott Meyers also uses this form in his 'Effective
    STL' book. ( I cannot verify it right now because the book is not with
    me )
    But I was wondering if this form is safe, in the strictest sense.
    The underlying question is ' does remove guarantee that the end()
    iterator is still valid after the operation' ? If it is not guaranteed
    and if the second parameter 'vec.end()' is evaluated first (before
    remove), then vec.erase will possibly get a new end as the first
    parameter, but an old/invalid end() iterator as the second.
    I hope I explained my question clearly.

    Thanks,
    Nan
     
    Nan Li, Nov 8, 2005
    #1
    1. Advertising

  2. Nan Li

    Ron Natalie Guest

    Nan Li wrote:
    > Hello,
    > I have seen people doing erase remove idiom like the following:
    >
    > ' vec.erase(remove_if(vec.begin(), vec.end(), is_odd<int>),
    > vec.end() );'
    >
    > I remember Scott Meyers also uses this form in his 'Effective
    > STL' book. ( I cannot verify it right now because the book is not with
    > me )
    > But I was wondering if this form is safe, in the strictest sense.
    > The underlying question is ' does remove guarantee that the end()
    > iterator is still valid after the operation' ? If it is not guaranteed
    > and if the second parameter 'vec.end()' is evaluated first (before
    > remove), then vec.erase will possibly get a new end as the first
    > parameter, but an old/invalid end() iterator as the second.
    > I hope I explained my question clearly.


    There is no guarantee on the order of execution, but none is required.
    The moving around of items in the sequence can't do anything that
    would invalidate the end() iterator since it's not evaluated at all
    during the execution of remove (it's passed in as an argument).
    This is one of the reasons hy remove doesn't actually remove anything.
     
    Ron Natalie, Nov 8, 2005
    #2
    1. Advertising

  3. "Ron Natalie" <> wrote in message
    news:43711727$0$9524$...
    > Nan Li wrote:


    >> But I was wondering if this form is safe, in the strictest sense.
    >> The underlying question is ' does remove guarantee that the end()
    >> iterator is still valid after the operation' ?


    > There is no guarantee on the order of execution, but none is required.
    > The moving around of items in the sequence can't do anything that
    > would invalidate the end() iterator since it's not evaluated at all
    > during the execution of remove (it's passed in as an argument).


    This is a good one to remember the next time you're looking for an interview
    question :)
     
    Andrew Koenig, Nov 8, 2005
    #3
    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. Piotr
    Replies:
    10
    Views:
    613
    Richard Herring
    Jan 19, 2006
  2. erase vs. erase

    , Mar 25, 2006, in forum: C++
    Replies:
    7
    Views:
    388
    Pete Becker
    Mar 30, 2006
  3. Replies:
    8
    Views:
    649
  4. Boltar
    Replies:
    6
    Views:
    2,277
    Jerry Coffin
    Jan 5, 2008
  5. Öö Tiib
    Replies:
    0
    Views:
    774
    Öö Tiib
    Jun 16, 2010
Loading...

Share This Page