Ist es sicher, push_back ein element aus der selben Vektor?

vector<int> v;
v.push_back(1);
v.push_back(v[0]);

Wenn die zweite push_back bewirkt eine Umverteilung der Verweis auf die erste Ganzzahl in der Vektor wird nicht mehr gültig sein. Also, das ist nicht sicher?

vector<int> v;
v.push_back(1);
v.reserve(v.size() + 1);
v.push_back(v[0]);

Ist es sicher?

Da ist ein Fehler in Visual Studio 2010: stackoverflow.com/questions/10218223/...
Ein Hinweis: Es gibt derzeit eine Diskussion in der standard-Vorschläge-forum. Als Teil davon, hat jemand eine Beispiel-Implementierung push_back. Ein weiteres Plakat bemerkt einen Fehler, dass es nicht ordnungsgemäß behandelt den Fall, den Sie beschreiben. Niemand sonst, soweit ich das beurteilen kann, argumentiert, dass dies nicht ein bug. Nicht sagen, dass schlüssigen Beweis, nur eine Beobachtung.
Tut mir Leid, aber ich weiß nicht, die Antwort zu akzeptieren, denn es gibt immer noch Streit über die richtige Antwort.
Ich denke, dass der "bug" war eine Frage der Robustheit arbeiten mit real-world-code, und nicht die Konformität.
Ähnlicher Fall: stackoverflow.com/questions/11511510/...
Ich wurde gebeten, zu kommentieren, auf diese Frage durch die 5. Kommentar unter: stackoverflow.com/a/18647445/576911. Ich bin dabei und upvoting jede Antwort, die derzeit sagt: ja, es ist sicher zu push_back ein element aus dem gleichen Vektor.
Werden Sie dann sagen, dass jeder Requires: Bedingung und Voraussetzung in der gesamten Norm gilt nur, wenn die Funktion aufgerufen wird, und Sie zu brechen, bevor die Funktion zurückkehrt, ist erlaubt, es sei denn er läuft in Konflikt mit irgendeiner anderen Regel? Denn das ist die einzige Möglichkeit, die Standard interpretiert wurde dies zulassen.
Ich sage, dass wenn dies nicht erlaubt, es müsste eine Erfordert verbieten es. Zum Beispiel siehe Tabelle 100 - Sequence-Anforderungen für container, a.insert(p,i,j), pre: i und j sind nicht Iteratoren in einem. Siehe auch [res.auf.Argumente]/p1/b3, der effektiv sagt, dass, wenn Sie tun v.push_back(move(v[0])); dann ist es nicht garantiert, um zu arbeiten. Wenn Sie etwas bewegen, die std::lib ist zulässig, zu vermuten, was Sie bewegt, ist wirklich ein prvalue. Aber ich kenne keine Einschränkungen in Bezug auf v.push_back(v[0]);. Zusätzlich ich bin mir bewusst, dass alle std::lib implementors hart arbeiten, um diese Arbeit zu machen.
Sie sagen also, dass, obwohl der Standard verlangt die übergabe eines gültigen Verweis auf push_back, es ist ok, um pass ein, dass Sie wissen, unterliegt der drohenden Abwertung? Mit dieser begrenzten Sicht auf die Funktionen Requires aka Voraussetzungen, ich könnte brechen die meisten, wenn nicht alle algorithmen beschrieben in der Norm.
Wenn Sie nicht einverstanden sind mit dem, was der standard sagt, oder auch wenn Sie einverstanden mit dem standard, aber glaube nicht, dass er sagt es deutlich genug, das ist immer eine option für Sie: cplusplus.github.io/LWG/lwg-aktiv.html#submit_issue habe ich diese Möglichkeit, mich öfter als ich mich erinnern kann. Manchmal erfolgreich, manchmal nicht. Wenn Sie möchten, zu diskutieren, was der standard sagt, oder was er sagen sollte, ALSO nicht ein wirksames forum. Unser Gespräch hat keine normative Bedeutung. Sie können aber eine chance haben, in eine normative Wirkung, indem Sie den link oben.
Sind Sie sicher, dass Sie konnte? Es gibt durchaus ein paar Regeln in der Algorithmen-Bibliothek über das, was Ihre Funktionen sind erlaubt, das zu tun.
ja, ziemlich sicher. Ich werde arbeiten müssen, bis es ein Beispiel nach der Arbeit und sehen, ob Sie können den Namen für jede Regel, die er verletzt.
Requires: ist eine Voraussetzung, nicht eine invariante.
Es gibt zwei verschiedene Definitionen für das Wort Invarianten auch. Eines ist eine Tatsache, ist immer wahr, wenn eine bestimmte Codezeile erreicht ist. Voraussetzung sicher qualifiziert, da diese Art von invariante. Ein weiterer ist die Tatsache, dass hält vom Ende der Konstruktor bis zum Beginn der Zerstörung, möglicherweise mit Ausnahmen, während ein lock gehalten wird. Diese zweite definition nicht wirklich zu Funktion Argumente (andere als Konstruktor-Argumente, die gespeichert werden für die Lebensdauer des Objekts an, zum Beispiel mit Mitglieder-Daten der Referenz-Typ).
Eine Voraussetzung gelten nicht als invariante. Eine invariante auf der anderen Seite ist auch eine Voraussetzung. Dass gesagt wird, eine invariante kann für jedes sub-Programm, ob eine Klasse, ein Modul, Methode, Funktion, Schleife oder einfache code-block. In Bezug auf die C++ - Spezifikationen, ich glaube Requires: bedeutet pre-Zustand, und nicht unveränderlich. Die Voraussetzung muss nur zu halten, die unmittelbar vor der Ausführung des sub-Programms.
Ist ein "loop-invariant" eine invariante? Ja, Voraussetzung ist eine invariante -- für mindestens einen trivialen (leeren) basic-block an den Anfang der Funktion.
Könnte mir jemand erklären, warum das erste Beispiel in der Frage wäre unsicher? Ich bin ein bisschen ein Neuling, und ich habe Probleme, warum es vielleicht sein könnte ist unsicher. Danke!
Wenn push_back bewirkt, dass der Vektor zu erreichen, die Kapazität, der Vektor Zuweisung einer neuen größeren Puffer, kopiere die alten Daten, und löschen Sie dann die alten Puffer. Dann wird es fügen das neue element ein. Das problem ist, das neue element ist ein Verweis auf Daten in der alten-Puffer, die gerade gelöscht wurde. Es sei denn, push_back macht eine Kopie des Werts, der vor dem löschen, es wird dann eine schlechte Referenz.

InformationsquelleAutor Neil Kirk | 2013-09-13

c++language-lawyer push-back reference vector

31

Sieht es aus wie http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526 adressiert dieses problem (oder etwas sehr ähnliches) als potentieller defekt in der standard:

1) Parameter per const-Referenz kann geändert werden, während der Ausführung
von der Funktion

Beispiele:

Gegeben std::vector v:

v. insert(v. begin(), v[2]);

v[2] kann verändert werden, indem man Elemente der Vektor -

Die vorgeschlagene Lösung war, dass es nicht ein Mangel:

vector::insert(iter, iter-Wert) ist erforderlich, um zu arbeiten, weil der standard
nicht die Erlaubnis geben, für Sie nicht zu funktionieren.
- Ich finde die Erlaubnis in 17.6.4.9: "Wenn ein argument einer Funktion hat einen ungültigen Wert (beispielsweise einen Wert, der außerhalb der Domäne der Funktion oder einen Zeiger ungültig für seine Verwendung), ist das Verhalten undefiniert." Wenn Umverteilung stattfindet, dann werden alle Iteratoren und Referenzen auf Elemente, die ungültig sind, d.h. die parameter-Referenz an die Funktion übergeben wird, ist ebenso hinfällig.
- Ich denke, der Punkt ist, dass die Umsetzung zuständig ist die Umverteilung. Es obliegt es zu gewährleisten, das Verhalten wird festgelegt, ob der Eingang wird zunächst definiert. Da die Angaben eindeutig festlegen, dass push_back macht eine Kopie, Implementierungen müssen, auf Kosten der Ausführungszeit vielleicht, cache oder kopieren Sie alle Werte vor dem aufheben der Zuordnung. Da in dieser Frage gibt es keine externen Verweise, Links, ist es egal, ob Iteratoren und Referenzen sind ungültig.
- Ich denke, das sollte die authorative Antwort, es ist auch erwähnt von Stephan T. Lavavej auf Reddit mit im wesentlichen die gleichen Argumente.
- v.insert(v.begin(), v[2]); nicht der Auslöser einer Umverteilung. Also, wie macht dies die Frage beantworten?
- ja, es kann natürlich der Auslöser einer Umverteilung. Sie sind die Erweiterung der Vektor ist eine Größe, die durch das einfügen ein neues element.
InformationsquelleAutor Nate Kohl
21

Ja, es ist sicher, und die standard-Bibliothek Implementierungen durch Reifen springen, um es so zu machen.

Ich glaube der Entwickler-trace-diese Forderung zurück auf 23,2/11 irgendwie, aber ich kann nicht herausfinden, wie, und ich kann nicht finden, etwas mehr Beton ist entweder. Die beste, die ich finden kann, ist dieser Artikel:

http://www.drdobbs.com/cpp/copying-container-elements-from-the-c-li/240155771

Inspektion von libc++und libstdc++'s Implementierungen zeigt, dass Sie auch sicher.
- Einige Unterstützung wäre wirklich hilfreich hier.
- Noch auf der Suche. Ich weiß, dass es da, muss es nur finden.
- Das ist interessant, ich muss zugeben, ich hatte nie bedacht, der Fall aber in der Tat scheint es sehr schwer zu erreichen. Tut es auch hält für vec.insert(vec.end(), vec.begin(), vec.end()); ?
- No: Tabelle 100, sagt: "pre: i und j sind nicht Iteratoren in einem".
- Ich bin upvoting nun dies ist meine Erinnerung auch, aber eine Referenz benötigt wird.
- vec.begin(), vec.end()); ist nie sicher, weil Iteratoren an und nach der Einfügemarke sind immer ungültig, auch wenn es keine Umverteilung, und vec.end() ist wie ein iterator.
- Ist 23.2/11 in der version, die Sie verwenden ", Sofern nichts anderes angegeben ist (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." ? Aber vector.push_back NICHT anderweitig angeben. "Ursachen Umverteilung, wenn die neue Größe größer ist als die alte Kapazität." und (bei reserve) "Neuzuweisung ungültig werden alle Referenzen, Pointer und Iteratoren unter Bezugnahme auf die Elemente in der Sequenz."
InformationsquelleAutor Sebastian Redl
13

Die Norm garantiert auch Ihr erstes Beispiel, um sicher zu sein. Zitieren C++11

[sequence.Bestand]

3 In Tabellen 100 und 101 ... X bezeichnet ein Sequenz-container-Klasse a zeigt einen Wert von X enthält Elemente des Typs T, ... t bezeichnet ein lvalue oder ein const rvalue von X::value_type

16 Tabelle 101 ...

Ausdruck a.push_back(t) Rückgabetyp void Operationelle Semantik Fügt eine Kopie der t. Erfordert: T wird CopyInsertable in X. Container basic_string, deque, list, vector

So, obwohl es nicht gerade trivial, die Implementierung muss garantieren, es wird nicht zum erlöschen der Referenz, wenn dabei die push_back.
- Huh? Wie ist, dass jeder sagen nichts über die übergabe einer Referenz, die den Anruf macht Sie ungültig?
- Ich sehe nicht, wie das garantiert diese sicher zu sein.
- Bitte nicht upvote, eine Antwort, die enthält Standardese, es sei denn, Sie verstehen die Standardese!
- Ich bin verwirrt. Wie funktioniert diese zeigen, dass die Kopie gemacht werden muss, bevor der container geändert wird?
- Ich denke "Fügt eine Kopie von t" bedeutet, dass die push_back verhält sich so, als wenn das argument wird als Wert übergeben. Ich bin mir nicht sicher, obwohl.
- Nicht, wenn die globalen Voraussetzungen verletzt werden, und die globalen Voraussetzungen, die Sie passieren nur gültige Referenzen...
- Es "Hängt eine Kopie von t". Wie kann man diese entkräften t? In der Zeit, die Sie übergeben Sie die Referenz gültig ist.
- Ist es absolut nicht entkräften t, die Frage ist nur, ob vor oder nach der Anfertigung der Kopie. Dein letzter Satz ist sicher falsch.
- Da t entspricht den aufgeführten Voraussetzungen, die das beschriebene Verhalten ist garantiert. Eine Implementierung ist nicht zulässig, ungültig, vorausgesetzt, und dann verwenden, die als Entschuldigung, sich nicht zu Verhalten, wie angegeben.
- Sie der Entwickler sind, der übergabe einer Referenz, die Sie kennen, nicht gültig für die Dauer des Gesprächs-Sie haben gegen die Voraussetzung.
- Der AUFTRAGGEBER ist nicht verpflichtet, die zur Aufrechterhaltung der Voraussetzung während des Aufrufs; nur, um sicherzustellen, dass es erfüllt ist, auf die Einleitung des Gesprächs.
- Ich bin nicht einverstanden. Zum Beispiel fordern Sie, dass std::for_each ist erforderlich, um zu arbeiten, auch wenn der Funktor wird, erlischt die end-iterator für den Bereich? Wie wäre es mal entdecken Sie die neue gültige Ende-iterator? Sie müssen sicherstellen, dass die Voraussetzungen erfüllt sind, in der gesamten Anruf.
- Ich denke, es wäre wirklich schlecht für die vector-wenn ich Sie interpretieren den text, wie Sie es tun.
- Ich denke, es gibt viele andere member-Funktionen und algorithmen, die keine Wahl haben, aber meine interpretation.
- Das ist ein guter Punkt, aber ich glaube, es geht darum, dass der Funktor übergeben for_each erforderlich ist, nicht zur Unwirksamkeit der Iteratoren. Ich kann nicht kommen mit einer Referenz für for_each, aber ich sehe auf einige algorithmen, die text wie "op und binary_op begründet nicht die Unwirksamkeit Iteratoren oder Teilbereiche".
- Es gibt auch accumulate und inner_product, partial_sum, und adjacent_difference.
- Grundsätzlich würde ich sagen, dass es die meisten algorithmen, die ein Funktor und sind nicht aufgeführt unter "Nicht-ändern der Reihenfolge von Operationen." Vielleicht hat jemand vergessen zu formalisieren, die überschrift als eine Voraussetzung?
- hat nichts damit zu tun, dass bezieht sich auf, ob der Algorithmus selbst wird ändern Sie die Reihenfolge. Keiner der algorithmen, die zur Arbeit gehen rechts, wenn seine callback-Funktor ändert die Sequenz iteriert in einer Weise, Iteratoren ungültig.
- Ahh ja, der Wortlaut war so unterschiedlich, dass ich nicht finden mit der Suche.
- Ich Art von wissen, aber dann wieder, z.B. der Funktor von std::for_each() ist erlaubt das ändern der Reihenfolge der Elemente.
- Ja, es kann ändern von Elementen, nicht aber die Sequenz-Struktur, denn das würde gegen die Globale Voraussetzung, dass die Iteratoren übergeben for_each gültig (für die Dauer des Gesprächs). (Gut, einige Container erlauben würde einige strukturelle Veränderungen vorgenommen und noch garantieren, dass Iteratoren und Referenzen bleiben gültig)
- Ahh, ich kam gerade über dieser Sitzung von Sean Parent auf channel9. Siehe die Umsetzung von commit() bei 19:11. Er hat geschrieben x.push_back(x.back());. Jetzt sehe ich, es ist jemand, der interpretiert den text wie ich es Tat.
- Sie erwarten Channel9-Sitzungen, um zu demonstrieren, portablen code?
- Ich Frage mich nur, ob Sean Parent falsch ist zu, und niemand scheint zu sehen, das problem in seiner demo.
- Code funktioniert auf Visual C++. Tut er behaupten, es funktioniert auf jedem anderen compiler/library? Er wäre nur falsch wenn er eine Behauptung über die Portabilität.
- Eine andere Antwort hat darauf hingewiesen, eine Bibliothek Mangels Bericht auf dieser und der Ausschuss beurteilt es als kein Mangel, sagen, es ist schon angegeben, dass dies sicher ist. Also ich würde sagen, Ihr Verständnis von 'Voraussetzung' entspricht dem konventionellen; das treffen Voraussetzungen bei der Einweihung der Anruf ist ausreichend zur Erfüllung der Voraussetzungen. Anforderungen an die funktoren zu vermeiden, Aufhebungs-während der Ausführung ist eine unabhängige Anforderung. Wenn es einen Mangel, dann ist es, dass die Spezifikation vernachlässigt, zu erklären, dass der Funktor for_each muss nicht die Unwirksamkeit reicht. @BenVoigt
- In der Richtung liegt der Wahnsinn. Die Requires: Dokumentation ist eine Voraussetzung, aber es ist nicht nur Voraussetzung. Es ist stärker. Oder halten Sie es für einen Fehler, die die Standard-vernachlässigt zu sagen, dass die copy-Konstruktoren müssen nicht ungültig Iteratoren und vernachlässigt zu sagen, dass move-Konstruktoren müssen nicht ungültig Iteratoren und vernachlässigt zu sagen, dass die Zuweisung Anrufe müssen nicht ungültig Iteratoren und das iterator-Inkrement-Funktionen müssen nicht Iteratoren ungültig werden. Das wird sehr chaotisch werden sehr schnell. Nein, die Requires: - Klauseln gelten für die gesamte Dauer des Gesprächs.
- bei den algorithmen, die besagen, dass funktoren müssen nicht die Unwirksamkeit der Reihe, es scheint, dass Sie bereits angeben, dass das kopieren, verschieben, etc. Betrieb nicht ungültig; Sie beschränken nicht deren Verbot auf die Ungültigkeit zu operator(). Aber ob das ein Mangel ist oder nicht, hat der Ausschuss war sich im klaren über die richtige interpretation der Anforderungen auf insert, die gewährleisten, dass diese gut definierten und tragbaren.
- Ich meine nicht binary_op's kopieren/verschieben/was auch immer, ich meine, für den element-Typ. Wenn Sie Lesen, die requires: als "zum Zeitpunkt des Aufrufs nur", ich finde Schlupflöcher überall.
- Dann sind Sie sicher, lassen Sie diese konsequent angegeben. Ich glaube nicht, dass es chaotisch, da könnte es ein paar Paragraphen, die für alle algorithmen ist, ähnlich der Art, wie Sie angeben, dass Sie passieren müssen gültige Bereiche in den ersten Platz (C++11 24.2.1/7, letzter Satz).
- Ich denke, es sollte explizit angegeben ja, aber ich denke, es sollte sein eine Globale Regel, die Voraussetzungen müssen eingehalten werden für die gesamte Dauer des Anrufs, mit wenigen lokalen Ausnahmen.
- Welchen nutzen würde das haben, außer, um es nicht mehr garantiert, dass dieser Anruf ist sicher? Mir ist es lieber, 'Voraussetzungen' streng Voraussetzungen und andere Anforderungen, wie etwa, dass Benutzer-code, genannt, indem der Algorithmus nicht die Unwirksamkeit reicht, angegeben werden, unabhängig. Es kann getan werden einfach und in einem globalen Ort wie die Sache über iterator reicht gültig.
- Damit das übergeben einer Referenz in denselben Vektor als ein besonderer Fall, hier in push_back und insert. Aber die Tatsache, dass die Anforderungen zu erwarten sind, um zu bleiben gültig für die Dauer des gesamten Anrufs ist ein sehr Allgemeines Prinzip. Und Nein, es gibt keinen Weg, um in der Regel geben Sie die Anforderung nicht entkräften, weil es speziell für die Parameter jedes Algorithmus.
- Sie haben nicht gezeigt, einen Vorteil zu machen, dies zu ändern. "- Anforderungen zu erwarten sind, bleiben gültig für die Dauer des gesamten Anrufs ist ein sehr Allgemeines Prinzip" ist Das nicht ein Voraussetzung: "eine Voraussetzung ist ein Zustand oder ein Prädikat, das immer wahr sein, kurz vor der Ausführung einige code-Abschnitt oder vor einer operation in eine formale Spezifikation."
- Der Standard ist voll von Anforderungen an die Anrufer, die der Begriff Voraussetzung nicht ausreichend beschrieben (diese Anforderungen sind Voraussetzungen und mehr)
- Der standard sagt ausdrücklich, dass die "Anforderungen" aufgeführt sind Voraussetzungen: 17.5.14/3
- Sie werden Voraussetzungen, denn Sie halten müssen, bevor der Anruf. Aber es muss nicht sagen, Sie sind nur erforderlich, um zu halten auf den Eintrag, noch kann es bedeuten, dass. Blick auf den nächsten Absatz -- es beschreibt äquivalent zu Semantik und Karten Vorbedingungen von Funktionen aufgerufen, die in der Mitte und am Ende der äquivalent zu code Voraussetzungen des Allgemeinen nennen, obwohl Sie brauchen, um zu halten, wenn dieser Aufruf erfolgt, nicht nur, wenn die Eltern eingetragen ist. Natürlich, Sie sind nicht mit dem Wort Voraussetzungen in der Weise, die Sie Sie sein wünschen.
- es nicht sagen, Sie sind nur erforderlich, um zu halten auf den Eintrag" Das ist genau das, was es sagt, und das ist, was der Ausschuss hat bekräftigt, dass Sie in der Antwort zur Bibliothek Frage 526. "Blick auf den nächsten Absatz" vector::push_back und vector::insert nicht haben "- Effekte: "- Klauseln und nicht angegeben, als 'Gleichwertig' einige code-Sequenz, so 17.5.1.4/4 nicht gelten.
- Damit die Bedeutung der Requires: und Voraussetzungen enthält die Dauer der Funktion für Klauseln, die den entsprechenden code, nicht aber für andere Klauseln?
- Nein, die Voraussetzungen einer Funktion sind immer nur erfüllt werden, wenn die Funktion aufgerufen wird. Die Vorbedingungen der aufgerufenen Funktionen in die entsprechende code nicht Voraussetzung der Funktion. Zum Beispiel: Sagen, dass Funktionen A und B haben keine Vorbedingungen und die Funktion C ist Voraussetzung x. Jetzt sagen A ist definiert als äquivalent zu B(); C();. x wird nicht zu einer Voraussetzung von(). Wenn das Voraussetzung nicht halten, dann ist es noch in Ordnung sein kann, call A() solange (B) stellt die Voraussetzung x für C().
- Außerdem, sagen, B hat postcondition y; y nicht zu einem postcondtion von A(), da C() verursachen könnte y nicht mehr wahr sein. Es ist also nicht wahr, dass 17.5.1.4/4 "Karten Vorbedingungen von Funktionen aufgerufen, die in der Mitte und am Ende des äquivalent-code, um die Vorbedingungen der gesamten Anruf." Das ist nicht das, was 17.5.1.4/4 ist zu sagen.
- Aber wenn x ist eine Voraussetzung für C() und B() hat keine Wirkung auf Sie, dann ist, wie beschrieben in A()'s Vertrag?
- Nicht als Vorbedingung, weil eine Voraussetzung würde bedeuten, es ist egal, ob B() hat eine Wirkung auf ihn haben oder nicht. @BenVoigt
- Aber Sie sind sich über die definition von "Voraussetzung" wie in die funktionale Programmierung. Es gibt eine zweite, umfassendere Bedeutung, das ist der Teil, der eine Funktion den Vertrag, die durch den Aufrufer. Die Funktion der Erfüllung seines Teils des Vertrages und der Bereitstellung von Garantien in Bezug auf Verhalten, Nebenwirkungen und Ergebnissen, z.B. auf der Aufrufer die Erfüllung seines Vertrages. Die Voraussetzung zunächst in einem logische Sinn, nicht unbedingt ein zeitliche Sinn.
- Ich verwende den Begriff im beabsichtigten Sinne von den Menschen, schrieb der standard, nicht zu erwähnen, dass es auch den Sinn, die allgemein in der Programmierung verwendet (und nicht nur die funktionale Programmierung. Siehe Eiffel, zum Beispiel, oder einfach nur Wikipedia.)
- Bei allem Respekt, wie kann man behaupten, dass Sie verwenden den Begriff als bestimmt durch die Normen-Ausschuss? Haben Sie mit Ihnen direkt?
- Weil Sie ist die Häufig verwendeten Sinn, und wenn der Ausschuss nicht verwenden es auf diese Weise, dann würde das bedeuten, dass die Spezifikation nicht geben Praktiker Breitengrad zu produzieren UB in diesem Fall: die Arbeitsgruppe Bibliothek die Antwort zu Frage 526 ist, dass diese "erforderlich ist, um zu arbeiten, weil der standard nicht die Erlaubnis geben, für Sie nicht zu arbeiten", was impliziert, dass Sie tatsächlich mit dem common sense der 'Voraussetzung'.
- Voigt: ich denke, dass Sie mitgebracht haben, bis ein sehr interessanter Punkt. Vielleicht solltest du eine neue Frage stellen ALSO, "Was ist die genaue Bedeutung von Voraussetzung, die im C++ standard?".
InformationsquelleAutor Reinstate Monica
7

Ist es nicht offensichtlich, dass im ersten Beispiel ist sicher, weil die einfachste Implementierung push_back wäre zunächst eine Neuverteilung des Vektors, falls benötigt, und kopieren Sie dann die Referenz.

Aber zumindest scheint es sicher zu sein, die mit Visual Studio 2010. Die Umsetzung der push_back macht die Besondere Handhabung der Fall, wenn Sie drücken Sie zurück, ein vector-element.
Der code ist wie folgt aufgebaut:
```
void push_back(const _Ty& _Val)
    {   //insert element at end
    if (_Inside(_STD addressof(_Val)))
        {   //push back an element
                    ...
        }
    else
        {   //push back a non-element
                    ...
        }
    }
```
- Das ist nicht ein problem hier, denn die Referenz ist nun angelegt, das nachdem die Umverteilung und Entwertung der Verweise.
- Warten Sie, sprechen Sie über die ersten oder zweiten snippet?
- Voigt: ich spreche über das erste snippet.
- Ich würde gerne wissen, ob die Spezifikation muss dieser sicher sein.
- Laut dem Standard ist es nicht erforderlich, um sicher zu sein. Es ist jedoch möglich, Sie zu implementieren, in einer sicheren Weise.
- Ich würde sagen, dass es wird erforderlich, um sicher zu sein (siehe meine Antwort).
- Dein Zitat sagt nichts dergleichen. Voraussetzung ist, dass Sie nur gültige Referenzen...
- In der Zeit, die Sie übergeben Sie die Referenz gültig ist.
- Das ist nicht ausreichend. Sie müssen übergeben Sie einen Verweis, der bleibt gültig für die Dauer des Anrufs, und diese nicht.
- Ich versuche hart zu verstehen, die Verbindung zwischen der Anweisung "Der erste Schnipsel ist natürlich nicht sicher" und der code, den Sie geschrieben.
- Se meine überarbeitete Antwort.
InformationsquelleAutor Johan Råde

Dies ist nicht eine Garantie der standard, aber als ein weiterer Datenpunkt, v.push_back(v[0]) ist sicher für LLVM libc zu benutzen++.

libc++'s std::vector::push_back Anrufe __push_back_slow_path bei Bedarf reservieren Speicher:

void __push_back_slow_path(_Up& __x) {
  allocator_type& __a = this->__alloc();
  __split_buffer<value_type, allocator_type&> __v(__recommend(size() + 1), 
                                                  size(), 
                                                  __a);
  //Note that we construct a copy of __x before deallocating
  //the existing storage or moving existing elements.
  __alloc_traits::construct(__a, 
                            _VSTD::__to_raw_pointer(__v.__end_), 
                            _VSTD::forward<_Up>(__x));
  __v.__end_++;
  //Moving existing elements happens here:
  __swap_out_circular_buffer(__v);
  //When __v goes out of scope, __x will be invalid.
}

Die Kopie hat nicht nur zu erfolgen, bevor die Freilassung der vorhandenen Speicher, aber bevor er aus den vorhandenen Elementen. Ich nehme an, der das verschieben der vorhandenen Elemente erfolgt in __swap_out_circular_buffer, in welchem Fall diese Umsetzung ist in der Tat sicher.
guter Punkt, und Sie sind in der Tat richtig, dass die Bewegung geschieht innerhalb __swap_out_circular_buffer. (Ich habe einige Kommentare Hinzugefügt, um beachten Sie, dass.)

InformationsquelleAutor Nate Kohl

1

Die erste version ist definitiv NICHT sicher:

Operationen auf Iteratoren erhalten durch den Aufruf einer standard-Bibliothek oder container, string-member-Funktion kann den Zugriff auf die zugrunde liegenden container, sondern wird sich nicht ändern. [ Hinweis: insbesondere container-Operationen, Iteratoren ungültig Konflikt mit Operationen, die auf Iteratoren im Zusammenhang mit diesem container. — Ende Hinweis ]

aus Abschnitt 17.6.5.9

Beachten Sie, dass in diesem Abschnitt auf Daten, die Rassen, die normalerweise Leute denken, der in Verbindung mit dem Durchzug... aber die eigentliche definition umfasst "passiert vor" Beziehungen, und ich sehe keine Bestellung Beziehung zwischen mehreren Nebenwirkungen von push_back im Spiel, nämlich der Verweis invalidation scheint nicht definiert zu werden wie bestellt mit Respekt zu kopieren-der Bau des neuen tail-element.
- Es sollte verstanden werden, dass der Hinweis, nicht die Regel, so ist es zu erklären, eine Folge der vorstehenden Regel... und die Konsequenzen sind identisch mit den Referenzen.
- Das Ergebnis v[0] ist kein iterator, ebenso push_back() nicht nehmen, einen iterator. Also, von einer Sprache, die Anwalt Perspektive, dein argument ist ungültig. Sorry. Ich weiß, dass die meisten Iteratoren sind Zeiger und der Punkt der Aufhebung, einen iterator, ist so ziemlich das gleiche wie für die Verweise, aber der Teil, von dem standard, den Sie zitieren, ist irrelevant für die situation auf der hand.
- -1. Es ist völlig irrelevant zitieren und nicht Antworten es trotzdem. Der Ausschuss sagt x.push_back(x[0]) ist SICHER.
InformationsquelleAutor Ben Voigt
0

Es ist völlig sicher.

In Ihrem zweiten Beispiel haben Sie
```
v.reserve(v.size() + 1);
```
ist nicht notwendig, da beim Vektor geht von seiner Größe, wird es bedeuten, dass der reserve.

Vektor ist verantwortlich für dieses Zeug, nicht Sie.

InformationsquelleAutor Zaffy
-1

Beide sind sicher, da push_back wird der Wert kopiert, nicht die Referenz. Wenn Sie die Speicherung von Zeigern, das ist immer noch sicher wie weit der Vektor betrifft, sondern nur wissen, dass man zwei Elemente der Vektor zeigt auf die gleichen Daten.
Abschnitt 23.2.1 Allgemeine Anforderungen Für Container

16
- ein.push_back(t t) Fügt eine Kopie von t. Erfordert: T ist CopyInsertable in X.
- ein.push_back(rv) Fügt eine Kopie von rv. Erfordert: T ist MoveInsertable in X.
Implementierungen von push_back müssen daher sicherstellen, dass eine Kopie v[0] eingefügt wird. Von counter Beispiel, vorausgesetzt, eine Umsetzung würde eine Neuverteilung vor dem kopieren, es würde nicht gewiß, hängen Sie eine Kopie von v[0] und als solche gegen die Spezifikationen.
- push_back wird, jedoch auch Größe des vectors aus und in eine naive Implementierung dieser wird ungültig machen die Referenz vor dem kopieren Auftritt. So, es sei denn, Sie kann dies durch ein Zitat aus dem standard, ich werde es prüfen falsch.
- Durch "dieses", meinst du das erste oder das zweite Beispiel? push_back kopieren Sie den Wert in den Vektor; aber (soweit ich sehen kann), dass etwas geschehen nachdem Umverteilung, an welchem Punkt der Referenz, die versuchen zu kopieren, ist nicht mehr gültig.
- push_back erhält das argument Verweis.
- Denken Sie über diese für eine zweite: Sie haben eine push_back-operation, die bewirkt, dass der Vektor, um die Größenänderung müssen. Tun Sie, ändern der Größe und löschen Sie den Puffer vor der Zugabe der push_back Wert, oder haben Sie die Größe, kopieren Sie alle Daten, einschließlich der push_back, und dann löschen Sie den alten Puffer?
- Entweder Weg, das Objekt (das als argument übergeben wird) existiert nicht mehr, sobald Sie die Größe des Vektors. Die Umverteilung, kopieren und löschen geschehen in einer anderen Funktion, die nicht wissen, etwas über push_back und argument.
- Es wäre zu (1) zuordnen, neue Raum, (2) kopieren Sie das neue element (3) verschieben-bauen Sie die bestehenden Elemente (4) zu zerstören, die bewegt-von den Elementen (5) frei, die alten Speicher-in dieser Reihenfolge-um die erste version arbeiten.
- Nur als Hinweis, das ist genau das, was die libc++ tut.
- Ihre interpretation von der Standard-Zitat ist völlig aus. Die Einschränkungen auf ein CopyInsertable Art in keiner Weise beschränken die Aktionen einer Funktion verwendet, die eine CopyInsertable geben.
- Guter Punkt. Ich habe geändert meine Antwort genauer zu sein.
- warum sonst würden Sie einen container benötigen, dass ein Typ sein CopyInsertable wenn es geht, komplett zu ignorieren, dass Eigentum überhaupt?
- Sie machen keinen Sinn. CopyInsertable ist eine Garantie, dass Ihr Typ macht auf den container, keine Garantie, dass der container macht für Sie. Betrachten Sie zum Beispiel die vector-Konstruktor, ein Muster und eine Zählung... es geht um die Kopie, die Muster oft, so erfordert es das Muster zu CopyInsertable und nicht verschwinden nach der ersten Kopie.
- Es klingt so, als wenn Sie jetzt argumentieren, dass, weil das argument ist CopyInsertable, dass push_back ist nicht erlaubt zu entkräften, Iteratoren und Referenzen auf alles, selbst nach der macht seine Kopie? Das ist eindeutig nicht eine angemessene interpretation.
- Ich spreche nicht über die Aufhebung von Iteratoren und Referenzen. Ich sage, dass nach push_back(v[0]), das Wert v[0] sein sollte, wie es vorher war, sagte push_back.
- Sie sprechen über die expression v[0], und nicht das Objekt(s) auf die er sich bezieht? Bist du jetzt eigentlich stretching mögliche Bedeutung von CopyInsertable.
- Die Wert v[0] ist per definition das Objekt, auf das es sich bezieht. In keiner Weise wird meine Aussage impliziert, dass die reference v[0] unverändert.
- lassen Sie uns weiter, diese Diskussion im chat
InformationsquelleAutor OlivierD
-2

Vom 23.3.6.5/1: Causes reallocation if the new size is greater than the old capacity. If no reallocation happens, all the iterators and references before the insertion point remain valid.

Da wir das einfügen am Ende, keine Referenzen werden ungültig wenn der Vektor nicht verändert. Also, wenn der Vektor s capacity() > size() dann ist es garantiert zu arbeiten, sonst ist es garantiert nicht definiertes Verhalten.
- Ich glaube, dass die Angabe tatsächlich garantiert dies funktioniert in jedem Fall. Ich warte auf einen Verweis, wenn.
- Es gibt keine Erwähnung von Iteratoren oder Iteratoren Sicherheit in Frage.
- der iterator Teil ist hier überflüssig: ich interessiere mich für die references Teil der Offerte.
- Es ist wirklich garantiert, um sicher zu sein (siehe meine Antwort, Semantik push_back).
InformationsquelleAutor Mark B

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

Abschnitt 23.2.1 Allgemeine Anforderungen Für Container