Re: vector.erase(iterator iter) will change "iter" or not?

From:

Richard Herring <junk@[127.0.0.1]>

Newsgroups:

comp.lang.c++

Date:

Tue, 26 Feb 2008 10:31:43 +0000

Message-ID:

<yY2ITJGPq+wHFwAj@baesystems.com>

In message
<79bc8204-9fcd-4cae-808b-d6b179de163c@v3g2000hsc.googlegroups.com>,
James Kanze <james.kanze@gmail.com> writes

On Feb 25, 5:40 pm, Richard Herring <junk@[127.0.0.1]> wrote:

In message
<a2f9ee21-5d0c-4728-b8ce-0837e6a15...@f47g2000hsd.googlegroups.com>,
James Kanze <james.ka...@gmail.com> writes

Old Wolf wrote:

[...]

I agree that it's legal, but I wouldn't expect it anywhere
except the DS9000; it seems that the implementation, when
faced with vector::erase, would have to go out of its way to
go and change bits in the original 'iter' that the parameter
to vector::erase was copied from.

I'm not sure what you mean by "go out of its way".

Iterate through every copy of every iterator ever generated
from that container, to see if it references the region that's
about to be invalidated?

Iterate through every copy of every iterator which currently
exists. Iterators which no longer exist don't matter.

"Iterators which no longer exist" don't exist - how _could_ you iterate
through them? :-/

And how
many iterators normally exist at any one time.

First you'd have to define "normally". It might be O(N) if you use
containers of iterators to represent indexes sorted on different
criteria. I don't say it's a good design, but it's certainly a possible
one.

Every pre-standard iterator I ever wrote did this.
Logically, the iterator knows about the container, and vice
versa.

But physically it need not: see implementations where
vector<T>::iterator is implemented as plain T*.

It's not *required* by the STL. All of the good implementations
do it.

No doubt, if you define "good" implementations as the ones that do it.
It's a shame they can't do the same for all the references and pointers
that also become invalidated.

It was in my pre-standard containers, where the
specifications didn't allow invalidating the iterator just
because it was convenient for the implementation. (In the case
of lists, there are other possibilities as well---my DLList
class actually didn't delete the node until there were no
iterators pointing to it, and the iterators managed a reference
count in the node.)

--
Richard Herring