«

Howard wrote:
>
> "Pete Becker" <> wrote in message
> news:...
> > joey tribbiani wrote:
> > >
> > > Why not the following?
> > >
> > > for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
> > > if (test(i)) {
> > > i = mymap.erase(i);
> > > }
> > > }
> >
> > Because map::erase returns void according to the standard. Our
> > implementation returns an iterator, just like vector::erase. The next
> > version of the standard will probably make that change official.
> >
>
> Even if it *did* return an iterator, the above code would only work if it

So tell the person who posted it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

"Pete Becker" <> wrote in message
news:...
> Jeff Flinn wrote:
> >
> > "Pete Becker" <> wrote in message
> > news:...
> > > joey tribbiani wrote:
> > > >
> > > > Why not the following?
> > > >
> > > > for (map<...>::iterator i = mymap.begin(); i != mymap.end(); i++) {
> > > > if (test(i)) {
> > > > i = mymap.erase(i);
> > > > }
> > > > }
> > >
> > > Because map::erase returns void according to the standard. Our
> > > implementation returns an iterator, just like vector::erase. The next
> > > version of the standard will probably make that change official.
> >
> > Even with this extension/future std, the above is incorrect. 'i' will be
> > effectively incremented twice for each true 'test(i)'. 'i++' needs to be
> > moved from the for statement to an else clause.
> >
>
> 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

Jeff Flinn wrote:
>
> > So tell the person who posted it.
>
> 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?

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

"Pete Becker" <> wrote in message
news:...
> Jeff Flinn wrote:
> >
> > > So tell the person who posted it.
> >
> > 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?
>
> --
>
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)

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

Howard wrote:
>
> "Pete Becker" <> wrote in message
> news:...
> > Jeff Flinn wrote:
> > >
> > > > So tell the person who posted it.
> > >
> > > 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?
> >
> 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*.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Howard wrote:
>>...
>> Since this function receives its parameter "by value" - yes, it actually
>> receives a copy of the original iterator.
>>
>
> 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.

--
Best regards,
Andrey Tarasevich

"Pieter Thysebaert" <> wrote in message news:c8010s$a5l$...
>
>
> 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





----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---