multimap erase

[sks]

I have a question regarding std::multimap/iterators.

At the SGI website, it says "Erasing an element from a multimap also does
not invalidate any iterators, except, of course, for iterators that actually
point to the element that is being erased."

I design/implemented a observer pattern that is priority based. It so
happened that observers were deregistering themselves while they were being
notified. In other words, we were iterating through the multipmap and the
iterator/observer we are currently on was being erased. I fixed this by
keeping a data member iterator (m_Next) that pointed to one past the current
observer. [there is more to my fix than this but the other stuff doesn't
really matter right now]

Suppose we had: { a, b, c, d, e }
I needed to use a reverse iterator to go from e to one past a for
notification.

Now, in my deregister, suppose we were notifying about c (m_Next would be
'b') and if c wanted to deregister itself, we would erase c without
invalidating m_Next.

This worked fine for the 2 observers that deregistered, however, while I was
notifying, I notified the same observer twice. It seemed to me that somehow
the rbtree readjusted and my iterator was now pointing to perhaps the "same"
node in the tree but that node had a different element in it now - is that
possible for a multimap? I think not given that quote I got from the SGI
website. Any thoughts here?

Here is the actual example:
Suppose we had: { a, b, c, d, e }
Observer d and b deregistered themselves while being notified. c is the
observer that was notified twice.
By the way, sorry about not posting any code - my class is quite complex and
I would have to rip apart a lot of the details (and compile) and post on
here.

By the way, I am doing my erase by doing this:
container.erase((+ri).base()); ri is the reverse_iterator. Even thought I am
doing this funky thing, the erase works fine.

I just want to know if any of you seen a multimap (or map) iterating over an
element/node multiple times. By the way, the element was only in there once.
I know this b/c I printed out the contents of the container right before
doing the notification.

Any thoughts? Thanks in advance.

[Alan Johnson]

sks wrote:

I have a question regarding std::multimap/iterators.

At the SGI website, it says "Erasing an element from a multimap also does
not invalidate any iterators, except, of course, for iterators that actually
point to the element that is being erased."

I design/implemented a observer pattern that is priority based. It so
happened that observers were deregistering themselves while they were being
notified. In other words, we were iterating through the multipmap and the
iterator/observer we are currently on was being erased. I fixed this by
keeping a data member iterator (m_Next) that pointed to one past the current
observer. [there is more to my fix than this but the other stuff doesn't
really matter right now]

Suppose we had: { a, b, c, d, e }
I needed to use a reverse iterator to go from e to one past a for
notification.

Now, in my deregister, suppose we were notifying about c (m_Next would be
'b') and if c wanted to deregister itself, we would erase c without
invalidating m_Next.

This worked fine for the 2 observers that deregistered, however, while I was
notifying, I notified the same observer twice. It seemed to me that somehow
the rbtree readjusted and my iterator was now pointing to perhaps the "same"
node in the tree but that node had a different element in it now - is that
possible for a multimap? I think not given that quote I got from the SGI
website. Any thoughts here?

Here is the actual example:
Suppose we had: { a, b, c, d, e }
Observer d and b deregistered themselves while being notified. c is the
observer that was notified twice.
By the way, sorry about not posting any code - my class is quite complex and
I would have to rip apart a lot of the details (and compile) and post on
here.

By the way, I am doing my erase by doing this:
container.erase((+ri).base()); ri is the reverse_iterator. Even thought I am
doing this funky thing, the erase works fine.

I just want to know if any of you seen a multimap (or map) iterating over an
element/node multiple times. By the way, the element was only in there once.
I know this b/c I printed out the contents of the container right before
doing the notification.

Any thoughts? Thanks in advance.

Which form of erase are you using? If you are using a reverse iterator
and calling base(), then you probably aren't erasing the element that
you think you are. Reverse iterators and iterators are related by the
following identity (see 24.4.1):
For an iterator i, &*(reverse_iterator(i)) == &*(i - 1)

So, if you have a reverse_iterator ri from a container c, the correct
way to erase the element it points to would be
c.erase(--ri.base()) ;

--
Alan Johnson

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On Feb 22, 7:11 am, Alan Johnson <[e-mail]:

sks wrote:

I have a question regarding std::multimap/iterators.

At the SGI website, it says "Erasing an element from a multimap also does
not invalidate any iterators, except, of course, for iterators that actually
point to the element that is being erased."

I design/implemented a observer pattern that is priority based. It so
happened that observers were deregistering themselves while they were being
notified. In other words, we were iterating through the multipmap and the
iterator/observer we are currently on was being erased. I fixed this by
keeping a data member iterator (m_Next) that pointed to one past the current
observer. [there is more to my fix than this but the other stuff doesn't
really matter right now]

Suppose we had: { a, b, c, d, e }
I needed to use a reverse iterator to go from e to one past a for
notification.

Now, in my deregister, suppose we were notifying about c (m_Next would be
'b') and if c wanted to deregister itself, we would erase c without
invalidating m_Next.

This worked fine for the 2 observers that deregistered, however, while I was
notifying, I notified the same observer twice. It seemed to me that somehow
the rbtree readjusted and my iterator was now pointing to perhaps the "same"
node in the tree but that node had a different element in it now - is that
possible for a multimap? I think not given that quote I got from the SGI
website. Any thoughts here?

Here is the actual example:
Suppose we had: { a, b, c, d, e }
Observer d and b deregistered themselves while being notified. c is the
observer that was notified twice.

By the way, sorry about not posting any code - my class is quite complex and
I would have to rip apart a lot of the details (and compile) and post on
here.

By the way, I am doing my erase by doing this:
container.erase((+ri).base()); ri is the reverse_iterator. Even thoughtI am
doing this funky thing, the erase works fine.

I just want to know if any of you seen a multimap (or map) iterating over an
element/node multiple times. By the way, the element was only in there once.
I know this b/c I printed out the contents of the container right before
doing the notification.

Any thoughts? Thanks in advance.

Which form of erase are you using? If you are using a reverse iterator
and calling base(), then you probably aren't erasing the element that
you think you are. Reverse iterators and iterators are related by the
following identity (see 24.4.1):
For an iterator i, &*(reverse_iterator(i)) == &*(i - 1)

So, if you have a reverse_iterator ri from a container c, the correct
way to erase the element it points to would be
c.erase(--ri.base()) ;

Speaking of reverse iterators, is there any special reason to use them
instead of normal iterators (like iterating from both ends on
different occasions)? If not you could use normal iterators and
construct the multimap with std::greater as comparator to get the same
effect.

--
Erik Wikström

[sks]

"Alan Johnson" <aw***@yahoo.comwrote in message
news:O4******************************@comcast.com. ..

>Which form of erase are you using? If you are using a reverse iterator

and calling base(), then you probably aren't erasing the element that you
think you are. Reverse iterators and iterators are related by the
following identity (see 24.4.1):
For an iterator i, &*(reverse_iterator(i)) == &*(i - 1)

So, if you have a reverse_iterator ri from a container c, the correct way
to erase the element it points to would be
c.erase(--ri.base()) ;

I am using the erase on the iterator - there isn't one for reverse_iterator.
In my implementation, I used "c.erase((++ri).base())" since that was what
Meyers recommended in his "Effective STL" book. I also assert that the
element I am pointing to by my reverse_iterator is the same as my iterator,
prior to the erase. The erase is definitely erasing the correct elements
since I check the container before and after.

[sks]

"Erik Wikström" <er****@student.chalmers.sewrote in message
news:11**********************@a75g2000cwd.googlegr oups.com...

Speaking of reverse iterators, is there any special reason to use them
instead of normal iterators (like iterating from both ends on
different occasions)? If not you could use normal iterators and
construct the multimap with std::greater as comparator to get the same
effect.

========================

Good idea. I will try that today.

Nothing tells me that my usage of reverse_iterator is screwing up the
container (iteration) but then again, it's probably better to use iter.
rather than reverse iter.

Thanks.