By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,515 Members | 1,848 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,515 IT Pros & Developers. It's quick & easy.

question about the stl erase-remove idiom

P: n/a
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

Nov 8 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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.
Nov 8 '05 #2

P: n/a
"Ron Natalie" <ro*@spamcop.net> wrote in message
news:43**********************@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 :-)
Nov 8 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.