ich würde gerne wissen wohin ein Iterator zeigt, wenn ich das Element aus dem STL Container lösche, auf das der Iterator zeigt. Ich habe eigentlich erwartet, daß der Iterator entweder auf das vorherige oder auf das nachfolgende Element zeigt. Aber das scheint nicht so zu sein und eine Spezifikation dazu hab ich auch nicht gefunden. Als Beispiel dient folgender Sourcecode:

multimap<unsigned int, Example *> aLotOfExamples;
  multimap<unsigned int, Example *>::iterator firstExample;
  pair<std::multimap<unsigned int, Example *>::iterator,
            std::multimap<unsigned int, Example *>::iterator> listOfDoublets;
  const unsigned int LIMIT    = 10;
  const unsigned int AMOUNT   = 10000000;
  unsigned int index          = 0;
  unsigned int key            = 0;
  unsigned int doomedExample  = 0;
  unsigned int doublets       = 0;
  unsigned int indexDoublets  = 0;

  srand(static_cast<unsigned int>(time(NULL)));

  for (index = 0; index < LIMIT; index++){
    firstExample = aLotOfExamples.insert(std::pair<unsigned int,
      Example *>(rand() % LIMIT, new Example()));
  }

  for (index = 0; index < LIMIT; index++){
    key = rand() % LIMIT;
    doublets = aLotOfExamples.count(key);
    if (0 < doublets){
      listOfDoublets = aLotOfExamples.equal_range(key);
      firstExample = listOfDoublets.first;
      indexDoublets = 0;
      doomedExample = rand() % doublets;
      while (indexDoublets < doomedExample){
        firstExample++;
        indexDoublets++;
      }
      delete firstExample->second;
      aLotOfExamples.erase(firstExample);

      // Whereto points firstExample now????
    }
  }

  for (firstExample = aLotOfExamples.begin();
    firstExample != aLotOfExamples.end(); firstExample++){
    delete firstExample->second;
  }
  aLotOfExamples.clear();

Grüße, M. Incani

...
ich würde gerne wissen wohin ein Iterator zeigt, wenn ich das Element aus dem STL Container lösche, auf das der Iterator zeigt. ...

Ganz einfach: Undefiniert !

Löschen macht alle iteratoren auf gelöschte Elemente ungültig.

Gruß,

Simon2.

wenn ich einen Container mit einer entsprechenden Operation zur Verfügung stellen würde, würde ich nach dem Löschen auf das darauf folgende Element zeigen, beziehungswese auf das vorherige wenn ich schon am Ende gewesen wäre. Nur wenn ich das einzige Element gelöscht hätte, hätte ich auf NULL verwiesen. Wenn das dem Anwender nicht passt, kann er immer noch von vorne beginnen. Etwas ähnliches hab ich auch bei den STL Containern erwartet und gemerkt, das es nicht so ist. Nur ist nichts dokumentiert. Zumindest habs ich nicht gefunden.

Grüße M. Incani

Simon2 schrieb:

BlackPepper schrieb:

...
ich würde gerne wissen wohin ein Iterator zeigt, wenn ich das Element aus dem STL Container lösche, auf das der Iterator zeigt. ...

Ganz einfach: Undefiniert !

Löschen macht alle iteratoren auf gelöschte Elemente ungültig.

Gruß,

Simon2.

wenn ich einen Container mit einer entsprechenden Operation zur Verfügung stellen würde, würde ich nach dem Löschen auf das darauf folgende Element zeigen, beziehungswese auf das vorherige wenn ich schon am Ende gewesen wäre. Nur wenn ich das einzige Element gelöscht hätte, hätte ich auf NULL verwiesen. Wenn das dem Anwender nicht passt, kann er immer noch von vorne beginnen. Etwas ähnliches hab ich auch bei den STL Containern erwartet und gemerkt, das es nicht so ist. Nur ist nichts dokumentiert. Zumindest habs ich nicht gefunden.

(ad Ändern) By Design werden Iteratoren eigentlich immer als Wert übergeben. Damit haben die entsprechenden Funktionen garnicht die Möglichkeit ihn zu ändern.

(ad Doku) Hast Du Dir schonmal die Dokumentation zu erase angeschaut? Bzw. was diese Funktion zurückliefert?

also ich habe nachgesehen in Kuhlins/Schrader: Die C++-Standardbibliothek (allerdings nur die 2 Auflage).

Wieso das im Standard so definiert, weiß ich jetzt auch nicht (bei vectoren ist mir das klar, aber hier (wo es nur die gelöschten Elemente betrifft) nicht).

Gruß,

Simon2.

Grüße M. Incani

LordJaxom schrieb:

(ad Ändern) By Design werden Iteratoren eigentlich immer als Wert übergeben. Damit haben die entsprechenden Funktionen garnicht die Möglichkeit ihn zu ändern.

(ad Doku) Hast Du Dir schonmal die Dokumentation zu erase angeschaut? Bzw. was diese Funktion zurückliefert?

leider hab ich das Buch nicht. Was steht denn dort?

Grüße M. Incani

Simon2 schrieb:

Hi,

also ich habe nachgesehen in Kuhlins/Schrader: Die C++-Standardbibliothek (allerdings nur die 2 Auflage).

Wieso das im Standard so definiert, weiß ich jetzt auch nicht (bei vectoren ist mir das klar, aber hier (wo es nur die gelöschten Elemente betrifft) nicht).

Gruß,

Simon2.

...
(ad Doku) Hast Du Dir schonmal die Dokumentation zu erase angeschaut? Bzw. was diese Funktion zurückliefert?

void multimap::erase( iterator pos );
size_type multimap::erase( const key_type& key );

helfen da nicht wirklich.

Gruß,

Simon2.

Hallo,
leider hab ich das Buch nicht. Was steht denn dort?
...

Naja. insgesamt hat es 400 Seiten und das Kapitel über Container immerhin auch fast 60. Du verzeihst mir, wenn ich das jetzt nicht abtippe, hoffe ich ...

Aber das Entscheidende ist:

Seite 105 (Kap. 7.2) schrieb:

void erase(iterator position);

[...]
Der Wert des Iterators ist nach dem Aufruf von erase nicht mehr definiert, weil der Element auf das er verwies, gelöscht wurde. erase(end()) hat keinen Effekt.
[...]
Bei allen drei Versionen der Elementfunktion erase verlieren nur Referenzen, Zeiger und Iteratoren auf gelöschte Containerelemente ihre Gültigkeit. Im Gegensatz zu den entsprechenden Funktionen sequentieller Container ist der Rückgabetyp für die beiden letzten Elementfunktionen void statt iterator [...], weil so die unter Umständen recht aufwändige BEstimmung des nachfolgenden Containerelements entfällt.

Übrigens:

BlackPepper schrieb:

...würde ich nach dem Löschen auf das darauf folgende Element zeigen, beziehungswese auf das vorherige wenn ich schon am Ende gewesen wäre. Nur wenn ich das einzige Element gelöscht hätte, hätte ich auf NULL verwiesen....

Ersteres fände ich "kernschlecht": "Mal auf das folgende, mal auf das vorherige verweisen" ?
Sorry, das ist total unbrauchbar. Außerdem wäre das Verhalten komplett anders als bei andern Containern, was den Umgang nicht einfacher machen würde (und einen Containertausch quasi unmöglich).

Zweiteres ist nicht nur wegen der "CopyÜbergabe" (s. LordJaxom) unmöglich (könnte man ja ändern), sondern deswegen weil es gar kein "NULL" bei Iteratoren gibt. Anders ausgedrückt: Du müsstest nicht nur den Container ändern, sondern auch die komplette Semantik von Iteratoren - und spätestens da, wo Iteratoren zu simplen Zeigern degenerieren, hättest Du den Bruch.

Gruß,

Simon2.

Naja. insgesamt hat es 400 Seiten und das Kapitel über Container immerhin auch fast 60. Du verzeihst mir, wenn ich das jetzt nicht abtippe, hoffe ich ...

Ausnahmsweise

Simon2 schrieb:

Aber das Entscheidende ist:

Seite 105 (Kap. 7.2) schrieb:

void erase(iterator position);

[...]
Der Wert des Iterators ist nach dem Aufruf von erase nicht mehr definiert, weil der Element auf das er verwies, gelöscht wurde. erase(end()) hat keinen Effekt.
[...]
Bei allen drei Versionen der Elementfunktion erase verlieren nur Referenzen, Zeiger und Iteratoren auf gelöschte Containerelemente ihre Gültigkeit. Im Gegensatz zu den entsprechenden Funktionen sequentieller Container ist der Rückgabetyp für die beiden letzten Elementfunktionen void statt iterator [...], weil so die unter Umständen recht aufwändige BEstimmung des nachfolgenden Containerelements entfällt.

Gruß,

Simon2.

Danke, das wollte ich wissen. Dein Buch scheint besser zu sein als meins. Muß ich mal unserer Bücherei sagen.

Grüße M. Incani

void multimap::erase( iterator pos );
size_type multimap::erase( const key_type& key );

helfen da nicht wirklich.

Ups. Tatsache. Da ist Dinkumware (meine Onlinereferenz) doch tatsächlich mal nicht 100% standardkonform, deren erase Methoden liefern den nächsten Iterator zurück.

...
Ausnahmsweise :-)...

Danke

Welches Buch hast Du denn ?
Zur Info: Ich habe mein letztes Post nochmal um Kommentare zu Deinem Containervorschlag erweitert.

Gruß,

Simon2.

...
Ups. Tatsache. Da ist Dinkumware (meine Onlinereferenz) doch tatsächlich mal nicht 100% standardkonform, deren erase Methoden liefern den nächsten Iterator zurück.

Das Gemeine ist ja, dass Du für andere Container Recht gehabt hättest !!
Finde ich nicht gerade optimal von den STL-Entwicklern ... bestimmt wieder ein Kompromiss oder "historisch gewachsen".

Gruß,

Simon2.

BlackPepper schrieb:

Nur ist nichts dokumentiert. Zumindest habs ich nicht gefunden.

In der ISO Norm steht genau drin, was bei erase passiert.
Für Sequenzen (siehe §23.1.1 Absatz 7 bzw. gilt genau das was Du beschreibst, S.erase(q) setzt q auf den Nachfolger von q. Im Zweifelsfall ist das S.end().
Für assoziative Container gilt dagegen § 23.1.2 Absatz 8. Nur die Iteratoren auf die gelöschten Elemente werden ungültig, alle anderen bleiben gültig.

MyContainer::iterator pos;
/* ... */
mycont.erase(pos++);

Dazu:
Vermutlich ist fuer sequentielle Container der Ausdruck

pos = mycont.erase(pos);

mindestens so effizient. Wie gross da die Unterschiede sind weiss ich nicht. Semantisch sehe ich keine Unterschiede, und fuer den Fall dass man sich spaeter noch fuer einen anderen, nicht-sequentiellen Container entscheidet, kann mans auf jeden Fall erstmal bei der ersten Version belassen (Optimierungen sollten ja sowieso immer erst gegen Ende der Entwicklung stattfinden).

BlackPepper schrieb:

...
Ausnahmsweise :-)...

Danke

Welches Buch hast Du denn ?
Zur Info: Ich habe mein letztes Post nochmal um Kommentare zu Deinem Containervorschlag erweitert.

Gruß,

Simon2.

Unsere Bücherei hat mehrere STL Bücher. Ich hab ISBN 0-321-41299-0

Grüße M. Incani

Also zu dem "mal nachfolgenden, mal vorherigen Element" - man kann immer einen nachfolgenden Iterator zurueckgeben, der nachfolgende des letzten Elements waeere dann end(). Meinen Vorpostern glaube ich entnehmen zu duerfen, dass das bei sequentiellen Containern (vector, deque &Co.) im Standard auch so gemacht wird, bei den anderen Containern ists nicht vorgeschrieben, aber die eine oder andere Bilbiothek (z.B. Dinkumware) machts trotzdem (ist aber dann nicht Standard => nicht portabel).

Das Problem dabei ist, daß mehrere Iteratoren auf das selbe Element zeigen könnten - erase() könnte aber nur bestenfalls den Iterator berichtigen, den du übergeben hast (und alle eventuell von dem erase() betroffenen Iteratoren zu finden dürfte wohl jede Laufzeit-Anforderung sprengen).

Folgendes sollte aber eigentlich fuer alle Container gehn:

MyContainer::iterator pos;
/* ... */
mycont.erase(pos++);

Nein, das fliegt dir bei vector<> (erase() macht alle Iteratoren ab der Löschposition ungültig) und deque<> (erase() könnte alle Iteratoren ungültig machen) vermutlich um die Ohren (oder liefert zumindest nicht das erwartete Ergebnis).

in meinem schlauen buch(die C++ Standardbiblothek) steht das bei allen container bei jeglicher einfuege / loeschoperation alle iteratoren des containers ungueltig werden können.

Ciao ...

Für eine multimap gibt es die folgenden erase Funktionen.

iterator erase(
iterator _Where
);
iterator erase(
iterator _First,
iterator _Last
);
size_type erase(
const key_type& _Key
);

Return Value:
For the first two member functions, a bidirectional iterator that designates the first element remaining beyond any elements removed, or a pointer to the end of the multimap if no such element exists.

Note that this return type does not conform to the C++ standard.

For the third member function, returns the number of elements that have been removed from the multimap.

...in meinem schlauen buch(die C++ Standardbiblothek) steht das bei allen container bei jeglicher einfuege / loeschoperation alle iteratoren des containers ungueltig werden ...

So hatte ich es auch in Erinnerung (und sogar zuerst geschrieben), dann aber nach genauerem Nachschlagen korrigiert.

Und mit

RHBaum schrieb:

...können. ...

kann man ja alles relativieren.
Aber mal in den Standard geschaut, ergibt:

23.1.2 Associative Containers Pkt 8 schrieb:

...The insert members shall not affect the validity of iterators and references to the container, and the erase members shall invalidate only iterators and references to te erased elements...

Gruß,

Simon2.

in meinem schlauen buch(die C++ Standardbiblothek) steht das bei allen container bei jeglicher einfuege / loeschoperation alle iteratoren des containers ungueltig werden können.

Das ist definitiv falsch. Alle Node-basierenden Container (list,map,set) haben naturgemäß stabile Iteratoren und Referenzen, die im Allgemeinen nur ungültig werden, wenn das betreffende Element zerstört wird. Und selbst für vector werden bei erase tatsächlich nur die letzten n (=Anzahl der gelöschten Elemente) Referenzen ungültig - da erase niemals zu Reallokationen führt und das Speicherlayout feststeht; der dem entgegenstehende Text im Standard dürfte ein Relikt von c++98 sein: dort war noch nicht festgelegt, dass die Elemente von vector ein Array bilden. Damit bleibt hier nur noch deque übrig: bei diesem Container ist diese Festlegung tatsächlich sinnvoll, es gibt mehre Möglichkeiten - mit unterschiedlichen Stabilitätsgarantien - um diesen Container zu implementieren.

Im allgemeinen Teil ueber iteratoren und container steht, dass bei einfuege und loeschoperationen die Zeiger / iteratoren etc die noch auf dem container sind, ungueltig werden können

bei der genauren beschreibung der einzelnen container steht dann:

liste: besonderheit beim insert, push_irgendwas etc bleiben alle iteratoren gueltig und bleiben auch auf den gleichen elementen.
beim erase() werden nur die Zeiger / iteratoren ungueltig, die auf das geloeschte Element gezeigt haben.

assoziative container: besonderheit beim insert, push_irgendwas etc bleiben alle iteratoren gueltig und bleiben auch auf den gleichen elementen.
beim erase() werden nur die Zeiger / iteratoren ungueltig, die auf das geloeschte Element gezeigt haben.

Also der einzige der seine Iteratoren versaubeutelt ist der vector

Die schreibweisse (3.Auflage) laesst aber schon den verdacht zu, dass da nachtraeglich kleinigkeiten veraendert wurden ... naja die STL ist besitmmt auch irgendwie gewachsen.

Ciao ...

Also der einzige der seine Iteratoren versaubeutelt ist der vector

Nicht ganz - die deque geht auch etwas rabiater mit ihren Iteratoren um.

vector: Einfüge-Operationen können ALLE Iteratoren vernichten (wenn der vector dabei seine Kapazität überschreitet - im Regelfall werden nur die Iteratoren hinter das Ziel ungültig), Lösch-Operationen nur Iteratoren auf oder hinter das Ziel.
deque: Einfüge- und Lösch-Operationen können alle Iteratoren ungültig machen (abgesehen von push_back(), push_front(), pop_back(), pop_front() - die sind "sicher") - idR betreffen sie nur den Bereich zwischen dem Ziel und dem näherliegenden Ende der deque.

Lösch-Operationen nur Iteratoren auf oder hinter das Ziel.

Beim vector referenziert der iterator doch die position, also den Index ?

wenn ich da das 1. element loesche, rutscht doch alles andere nach ? Damit sind die iteratoren ja vielleicht noch gueltig, aber zeigen nimmer auf die urspruenglichen elemente ?

und im schlimmsten fall ist es doch der STL Impl ned verboten, bei nem loeschen auf dem 1. element den kompletten vector neu zu bauen ?

Ciao ...