Re: vector.erase(iterator iter) will change "iter" or not?
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. And how
many iterators normally exist at any one time.
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. 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.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34