question about the stl erase-remove idiom



 DEVELOP > c-Plus-Plus > question about the stl erase-remove idiom

LINK TO THIS PAGE  


rating :  0   |  0


  Page 1 of 1

1

 
Topic: DEVELOP > c-Plus-Plus
User: "Nan Li"
Date: 08 Nov 2005 03:09:53 PM
Object: question about the stl erase-remove idiom
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
.

User: "Ron Natalie"

Title: Re: question about the stl erase-remove idiom 08 Nov 2005 03:27:04 PM
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.
.
User: "Andrew Koenig"

Title: Re: question about the stl erase-remove idiom 08 Nov 2005 03:46:24 PM
"Ron Natalie" <ron@spamcop.net> wrote in message
news:43711727$0$9524$9a6e19ea@news.newshosting.com...

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



  Page 1 of 1

1

 


Related Articles
 

NEWER

pg.1232     pg.940     pg.716     pg.544     pg.412     pg.311     pg.234     pg.175     pg.130     pg.96     pg.70     pg.50     pg.35     pg.24     pg.16     pg.10     pg.6     pg.3     pg.1

OLDER