Iterator Aufhebungs-Regeln

C++17 (Alle Referenzen sind aus der abschließenden Arbeitsentwurf CPP17 - n4659)

Einsetzen

Sequenz-Containern

• vector: Die Funktionen insert, emplace_back, emplace, push_back Ursache Umverteilung, wenn die neue Größe größer ist als die alte Kapazität. Neuzuweisung ungültig werden alle Referenzen, Pointer und Iteratoren unter Bezugnahme auf die Elemente in der Sequenz. Wenn keine Umverteilung
  geschieht, werden alle Iteratoren und Referenzen, bevor Sie die Einfügemarke bleiben gültig. [26.3.11.5/1]
  
  Mit Bezug auf die reserve Funktion, Neuzuweisung ungültig werden alle Referenzen, Pointer und Iteratoren unter Bezugnahme auf die Elemente in der Sequenz. Keine Umverteilung erfolgt während Einfügungen passieren, dass nach einem Aufruf reserve() bis zu der Zeit, wenn eine Einfügung machen würde, die Größe des Vektors größer ist als der Wert der capacity(). [26.3.11.3/6]

• deque: Eine insertion in der Mitte der deque ungültig alle Iteratoren und Referenzen auf Elemente der deque. Eine Einfügung am Ende der deque ungültig alle Iteratoren auf die deque, hat aber keine Auswirkung auf die Gültigkeit von Referenzen auf Elemente der deque. [26.3.8.4/1]

• list: Berührt das nicht die Gültigkeit von Iteratoren und Referenzen. Wenn eine exception geworfen wird, gibt es keine Wirkung. [26.3.10.4/1].
  
  Die insert, emplace_front, emplace_back, emplace, push_front, push_back Funktionen sind unter diese Regel.

• forward_list: Keiner der überlastung der insert_after soll hierdurch die Gültigkeit von Iteratoren und Referenzen [26.3.9.5/1]

• array: Als Regel, Iteratoren zu einem array sind nie für ungültig erklärt während der gesamten Lebensdauer des Arrays. Sollte man jedoch beachten, dass während der swap, der iterator wird weiterhin auf das gleiche array-element, und somit seinen Wert ändern.

Assoziative Container

• All Associative Containers: Die insert und emplace Mitglieder berührt nicht die Gültigkeit von Iteratoren und Referenzen auf container [26.2.6/9]

Ungeordnete Assoziative Container

• All Unordered Associative Containers: Aufwärmen Iteratoren ungültig, änderungen der Bestellung zwischen den Elementen, und die Veränderungen, die Eimer Elemente angezeigt, aber nicht außer Kraft, die Zeiger oder Referenzen auf Elemente. [26.2.7/9]
  
  Die insert und emplace Mitglieder berührt nicht die Gültigkeit der Referenzen auf container-Elemente, aber möglicherweise ungültig alle Iteratoren auf die container. [26.2.7/14]
  
  Die insert und emplace Mitglieder berührt nicht die Gültigkeit von Iteratoren, wenn (N+n) <= z * B, wo N ist die Anzahl der Elemente im container vor der insert-operation, n ist die Anzahl der eingefügten Elemente, B ist der container, die Eimer zu zählen, und z ist der container die maximale Auslastung. [26.2.7/15]

• All Unordered Associative Containers: Im Falle eines merge-Vorgangs (z.B. a.merge(a2)), Iteratoren bezogen auf die übertragenen Elemente und alle Iteratoren bezogen auf a für ungültig erklärt werden, aber Iteratoren auf Elemente noch in a2 gültig bleiben. (Tabelle 91 — Ungeordnete assoziative container)

Container Adapter

• stack: geerbt von den zugrunde liegenden container
• queue: geerbt von den zugrunde liegenden container
• priority_queue: geerbt von den zugrunde liegenden container

Löschung

Sequenz-Containern

• vector: Die Funktionen erase und pop_back ungültig Iteratoren und Referenzen an oder nach dem Punkt, der auf "löschen". [26.3.11.5/3]

• deque: Eine erase-Vorgang, löscht das Letzte element aus einem deque ungültig macht nur der past-the-end-iterator und alle Iteratoren und Verweise auf die gelöschten Elemente. Eine löschen-operation, löscht das erste element eines deque aber nicht das Letzte element ist ungültig nur Iteratoren und Verweise auf die gelöschten Elemente. Eine löschen-operation, löscht weder das erste element nicht das Letzte element einer deque erlischt die past-the-end-iterator und alle Iteratoren und Referenzen auf alle Elemente des deque.
  [ Hinweis: pop_front und pop_back sind erase operations. —Ende Anmerkung ] [26.3.8.4/4]

• list: Invalidiert werden nur die Iteratoren und Verweise auf die gelöschten Elemente. [26.3.10.4/3]. Dies gilt für erase, pop_front, pop_back, clear Funktionen.
  
  remove und remove_if member-Funktionen: Löscht alle Elemente in der Liste nach, indem Sie eine Liste mit iterator i für die die folgenden Bedingungen halten: *i == value, pred(*i) != false. Invalidiert werden nur die Iteratoren und Verweise auf die gelöschten Elemente [26.3.10.5/15].
  
  unique member-Funktion - Löscht alle, aber das erste element von jeder aufeinanderfolgenden Gruppe von gleichen Elementen bezeichnet, die durch den iterator i im Bereich [first + 1, last) für die *i == *(i-1) (für die version der einzigartigen, ohne Argumente) oder pred(*i, *(i - 1)) (für die version von unique mit einer Prädikat-argument) hält. Invalidiert werden nur die Iteratoren und Verweise auf die gelöschten Elemente. [26.3.10.5/19]

• forward_list: erase_after sind ungültig, nur Iteratoren und Verweise auf die gelöschten Elemente. [26.3.9.5/1].
  
  remove und remove_if member-Funktionen - Löscht alle Elemente in der Liste nach, indem Sie eine Liste mit iterator i, für die die folgenden Bedingungen halten: *i == value (für remove()), pred(*i) ist wahr (für remove_if()). Invalidiert werden nur die Iteratoren und Verweise auf die gelöschten Elemente. [26.3.9.6/12].
  
  unique member-Funktion - Löscht alle, aber das erste element von jeder aufeinanderfolgenden Gruppe von gleichen Elemente bezeichnet, auf die der iterator i im Bereich [first + 1, last), für die *i == *(i-1) (für die version ohne Argumente) oder pred(*i, *(i - 1)) (für die version mit einer Prädikat-argument) hält. Invalidiert werden nur die Iteratoren und Verweise auf die gelöschten Elemente. [26.3.9.6/16]

• All Sequence Containers: clear ungültig werden alle Referenzen, Pointer und Iteratoren unter Bezugnahme auf die Elemente von a und kann zum erlöschen der past-the-end-iterator (Tabelle 87 — Sequence-Anforderungen für container). Aber für forward_list, clear hat nicht die Unwirksamkeit past-the-end-Iteratoren. [26.3.9.5/32]

• All Sequence Containers: assign ungültig werden alle Referenzen, Pointer und
  Iteratoren Bezugnahme auf die Elemente des Containers. Für vector und deque auch kein past-the-end-iterator. (Tabelle 87 — Sequence-Anforderungen für container)

Assoziative Container

• All Associative Containers: Die erase Mitglieder erlöschen nur Iteratoren und Verweise auf die gelöschten Elemente [26.2.6/9]

• All Associative Containers: Die extract Mitglieder erlöschen nur Iteratoren auf das entfernte element; Zeiger und Referenzen auf entfernte element bleiben gültig [26.2.6/10]

Container Adapter

• stack: geerbt von den zugrunde liegenden container
• queue: geerbt von den zugrunde liegenden container
• priority_queue: geerbt von den zugrunde liegenden container

Allgemeine Behälter-Anforderungen an iterator-Invalidierung:

• Sofern nicht anders angegeben (entweder explizit oder indem Sie eine Funktion definieren, die in Bezug auf andere Funktionen), das aufrufen eines container-member-Funktion oder der übergabe der container als argument, um eine library-Funktion wird nicht ungültig Iteratoren an, oder ändern Sie die Werte der Objekte im container. [26.2.1/12]

• kein swap() Funktion ungültig macht, keine Referenzen, Zeigern oder Iteratoren Bezugnahme auf die Elemente der Container getauscht. [ Hinweis: Der end() iterator bezieht sich nicht auf ein beliebiges element, so kann es für ungültig erklärt werden. —Ende Hinweis ] [26.2.1/(11.6)]

Als Beispiele für die oben genannten Anforderungen:

• transform Algorithmus: Die op und binary_op Funktionen begründet nicht die Unwirksamkeit Iteratoren oder Teilbereiche oder ändern von Elementen in die Bereiche [28.6.4/1]

• accumulate Algorithmus: Im Bereich [first, last], binary_op weder ändern von Elementen noch die Iteratoren ungültig werden oder Teilbereiche [29.8.2/1]

• reduce Algorithmus: binary_op weder Iteratoren ungültig oder Teilbereiche, noch ändern-Elemente im Bereich [first, last]. [29.8.3/5]

und so weiter...

InformationsquelleAutor P.W

C++11 (Quelle: Iterator Aufhebungs-Regeln (C++0x))

Einsetzen

Sequenz-Containern

• vector: alle Iteratoren und Referenzen vor dem Punkt einsetzen, sind davon nicht betroffen, es sei denn, der neue container-Größe größer ist als die bisherige Leistung (in dem Fall alle Iteratoren und Referenzen ungültig werden) [23.3.6.5/1]
• deque: alle Iteratoren und Referenzen sind ungültig, es sei denn, die eingefügt Mitglied ist an einem Ende (vorne oder hinten) der deque (in dem Fall werden alle Iteratoren ungültig werden, aber Verweise auf Elemente sind davon nicht betroffen) [23.3.3.4/1]
• list: alle Iteratoren und Referenzen unberührt [23.3.5.4/1]
• forward_list: alle Iteratoren und Referenzen unberührt (gilt für insert_after) [23.3.4.5/1]
• array: (n/a)

Assoziative Container

• [multi]{set,map}: alle Iteratoren und Referenzen unberührt [23.2.4/9]

Unsortierte assoziative Container

• unordered_[multi]{set,map}: alle Iteratoren ungültig, wenn die Aufbereitung erfolgt, sondern verweist unberührt [23.2.5/8]. Aufwärmen nicht Auftritt, wenn die Einfügung nicht zu den container-Größe zu überschreiten z * B wo z ist der maximale load-Faktor und die B die aktuelle Anzahl der buckets. [23.2.5/14]

Container Adapter

• stack: geerbt von den zugrunde liegenden container
• queue: geerbt von den zugrunde liegenden container
• priority_queue: geerbt von den zugrunde liegenden container

Löschung

Sequenz-Containern

• vector: jeder iterator und das Referenz-oder nach dem löschen ist ungültig [23.3.6.5/3]
• deque: beim löschen des letzten Elements ist ungültig nur Iteratoren und Verweise auf die gelöschten Elemente und die past-the-end-iterator, löschen das erste element ist ungültig nur Iteratoren und Verweise auf die gelöschten Elemente, löschen alle anderen Elemente ungültig alle Iteratoren und Verweise (einschließlich der past-the-end-iterator) [23.3.3.4/4]
• list: es werden nur die Iteratoren und Referenzen auf das gelöschte element ist ungültig [23.3.5.4/3]
• forward_list: es werden nur die Iteratoren und Referenzen auf das gelöschte element ist ungültig (gilt für erase_after) [23.3.4.5/1]
• array: (n/a)

Assoziative Container

• [multi]{set,map}: nur Iteratoren und Verweise auf die gelöschten Elemente werden für ungültig erklärt [23.2.4/9]

Ungeordnete assoziative Container

• unordered_[multi]{set,map}: nur Iteratoren und Verweise auf die gelöschten Elemente werden für ungültig erklärt [23.2.5/13]

Container Adapter

• stack: geerbt von den zugrunde liegenden container
• queue: geerbt von den zugrunde liegenden container
• priority_queue: geerbt von den zugrunde liegenden container

Größenänderung

• vector: nach einfügen/löschen [23.3.6.5/12]
• deque: nach einfügen/löschen [23.3.3.3/3]
• list: nach einfügen/löschen [23.3.5.3/1]
• forward_list: nach einfügen/löschen [23.3.4.5/25]
• array: (n/a)

Hinweis 1

Sofern nicht anders angegeben (entweder
explizit oder durch definieren einer Funktion
in Bezug auf die anderen Funktionen) aufrufen
ein container member-Funktion oder die Weitergabe
einen container als argument, um ein
library-Funktion wird nicht ungültig
Iteratoren an, oder ändern Sie die Werte,
Objekte innerhalb des Containers.
[23.2.1/11]

Note 2

kein swap () - Funktion ist ungültig alle
Referenzen, Zeigern oder Iteratoren
bezogen auf die Elemente der
Behälter getauscht. [ Hinweis: Die
end () - iterator bezieht sich nicht auf irgendeine
element, so dass es kann für ungültig erklärt werden.
—Ende Anmerkung ] [23.2.1/10]

Anmerkung 3

Anderen als dem oben genannten VORBEHALT bezüglich swap(), es ist nicht klar, ob "Ende" - Iteratoren sind vorbehaltlich der oben aufgeführten pro-container-Regeln; Sie sollten davon ausgehen, dass, eh, dass Sie sind.

Anmerkung 4

vector und alle ungeordnete assoziative Container unterstützen reserve(n) die garantiert, dass keine automatische Größenänderung auftreten wird, wenigstens solange, bis die Größe der container wächst auf n. Vorsicht sollte genommen werden, mit ungeordnete assoziative Container, weil ein künftiger Vorschlag erlauben die Spezifikation einer minimalen load factor, die es erlauben würde, Aufbereitung erfolgen insert nach genug erase Operationen reduzieren die container-Größe unter der Mindest -; die Garantie sollte als potenziell nichtig nach einer erase.

InformationsquelleAutor Lightness Races in Orbit

Da diese Frage zieht so viele Stimmen und Art wird ein FAQ, ich denke, es wäre besser zu schreiben, eine separate Antwort zu schweigen von einem signifikanten Unterschied zwischen C++03 und C++11 in Bezug auf die Auswirkungen von std::vector's einfügen-operation auf die Gültigkeit von Iteratoren und Referenzen mit Bezug auf reserve() und capacity(), die die meisten von Ihnen positiv bewertet werden Antwort übersehen.

C++ 03:

Neuzuweisung ungültig werden alle Referenzen, Pointer und Iteratoren
bezogen auf die Elemente in der Sequenz. Es ist sichergestellt, dass keine
Umverteilung stattfindet, während Einfügungen passieren, dass nach einem Aufruf von
reserve (), bis die Zeit, wenn eine Einfügung machen würde, die Größe der
Vektor größer als die angegebene Größe in der jüngsten Aufruf
reserve().

C++11:

Neuzuweisung ungültig werden alle Referenzen, Pointer und Iteratoren
bezogen auf die Elemente in der Sequenz. Es ist sichergestellt, dass keine
Umverteilung stattfindet, während Einfügungen passieren, dass nach einem Aufruf von
reserve (), bis die Zeit, wenn eine Einfügung machen würde, die Größe der
Vektor größer als der Wert der Kapazität().

So, in C++03, es ist nicht "unless the new container size is greater than the previous capacity (in which case all iterators and references are invalidated)" wie bereits in der anderen Antwort, stattdessen sollte es "greater than the size specified in the most recent call to reserve()". Das ist eine Sache, C++03 unterscheidet sich von C++11. In C++03, sobald ein insert() bewirkt, dass die Größe des Vektors zu erreichen, wird der angegebene Wert in der vorherigen reserve() nennen (die auch kleiner als die aktuelle capacity() da ein reserve() könnte die Folge eine größere capacity() als gefragt), alle nachfolgenden insert() verursachen könnte, Umverteilung und ungültig alle Iteratoren und Referenzen. In C++11, das wird nicht passieren, und Sie können immer darauf Vertrauen capacity() mit Sicherheit zu wissen, dass die nächste Umschichtung wird nicht stattfinden, bevor die Größe überführungen capacity().

Abschließend, wenn Sie mit einem C++ - 03 Vektor-und Sie wollen sicherstellen, dass eine Umverteilung nicht passieren, wenn Sie ausführen, einführen, es ist der Wert des Arguments, die Sie zuvor übergeben reserve() , sollten Sie überprüfen Sie die Größe vor, nicht den Rückgabewert von einem Aufruf capacity(), sonst können Sie sich selbst überrascht über ein "vorzeitige" Umverteilung.

InformationsquelleAutor neverhoodboy