STL std::map erase

[Pete Becker]

Even if it *did* return an iterator, the above code would only work if it

So tell the person who posted it.

 

[Jeff Flinn]

So tell the person who posted it.

Assuming this thread is important to the OP, I just did.

I'm also telling someone googling down this thread a few years hence, when
the T::iterator is the standard, that this needs to be corrected.

Jeff F

 

[Pete Becker]

Assuming this thread is important to the OP, I just did.

Sigh. Okay. RESPOND TO THE PERSON WHO ORIGINALLY POSTED THE WORDS THAT
YOU THINK ARE INCORRECT. Is it really that hard to grasp?

 

[Howard]

Sigh. Okay. RESPOND TO THE PERSON WHO ORIGINALLY POSTED THE WORDS THAT
YOU THINK ARE INCORRECT. Is it really that hard to grasp?

Why are you so upset??? So our responses fall under yours instead of
directly under joey's. So what? He should be perfectly capable of seeing
the whole conversation, and the context of the responses. (Aren't you?)
It's not like we sent emails to you personally. We posted them to the
newsgroup, as follow-ups to your response. There's no sense in now going
back and posting *again*, directly to joey's post, just so he (and everyone
else) can read the same answer for the third time. Relax a little. We're
not attacking you, just posting follow-up info to the conversation.

-Howard

 

[Pete Becker]

Why are you so upset??? So our responses fall under yours instead of
directly under joey's. So what?

So you confuse things when you respond to the wrong message. I really
don't see why that's so hard to grasp.

He should be perfectly capable of seeing
the whole conversation, and the context of the responses. (Aren't you?)
It's not like we sent emails to you personally. We posted them to the
newsgroup, as follow-ups to your response. There's no sense in now going
back and posting *again*, directly to joey's post, just so he (and everyone
else) can read the same answer for the third time.

Sigh. Nobody suggested posting *again*.

 

[Andrey Tarasevich]

Ok...but then, what if you were to pass the iterator *by reference* to some
function instead? What value would the function then get, (considering the
previously stated rule that the increment side-effect has to be completed
prior to the calling of the function)? Would a temporary (un-incremented)
copy be created, passed by reference, and then that copy destroyed after the
return of the function? (That seems to be the only way to maintain the
concept of post-increment without violating the side-effect rule.)

Yes, that's pretty much correct. Note that if you make an attempt to
pass it by non-constant reference, the code simply won't compile,
because post-increment normally returns an rvalue and non-constant
reference cannot be bound to an rvalue. But if the function is declared
with constant reference parameter, then everything will work as you
describe, i.e. the reference will be bound to a temporary object, which
holds the original (un-incremented) value.

 

[Robbie Hatley]

Hello,

I've got a question conerning erasing key-value pairs from a std::map while
iterating over it.

According to the STL docs, erasing an element in a map invalidates all
iterators pointing to that element

so

for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
if (test(i)) {
mymap.erase(i);
mymap.insert(newelement);
}
}

looks like bad practice, and it does crash when it gets executed, at least
on one machine i've run such code on.

So my question is, how do I conveniently erase the "current" element in a
map on the fly while I'm iterating over it? (I admit that this sounds as
weird in English as it sounds in C++)?

Thanx,

Pieter

I've run into that situation many times with maps, lists and other containers,
and the easiest solution, I've found, is to get a copy of i called j, decrement i,
then erase (*j). Like so:

map<K, V> mymap; // where K and V are types
map<K, V>::iterator i, j; // get some iterators
for (i = mymap.begin(); i != mymap.end(); i++)
{
if (test(i))
{
j = i; // get temp. copy of i
--i; // gonna kill place where i pointed, so back up!
mymap.erase(j); // erase element where i used to point
mymap.insert(newelement); // automatically sorted; where did it go?
}
}

If i was decremented and (*j) erased, then when execution resumes at the
top of the loop, i will be incremented to the next un-erased item.

Also be aware that there's no guarantee the inserted item went the same
place as the deleted one; map is automatically sorted by key, so the new
element could end up anywhere, depending on sort order.


--
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant