Rechtmäßigkeit der Implementierung von COW std :: string in C ++ 11

Ich hatte verstanden, dass Copy-on-Write kein praktikabler Weg ist, um eine Konformität std::stringin C ++ 11 zu implementieren , aber als es kürzlich in der Diskussion auftauchte, war ich nicht in der Lage, diese Aussage direkt zu unterstützen.

Stimmt es, dass C ++ 11 keine COW-basierten Implementierungen von zulässt std::string?

Wenn ja, wird diese Einschränkung ausdrücklich irgendwo in der neuen Norm angegeben (wo)?

Oder ist diese Einschränkung impliziert, in dem Sinne , dass es die kombinierte Wirkung der neuen Anforderungen an ist , std::stringdass verbietet eine KUH - basierte Implementierung von std::string. In diesem Fall würde mich eine Kapitel- und Versstilableitung von "C ++ 11 verbietet COW-basierte std::stringImplementierungen" interessieren .

Dies ist nicht zulässig, da gemäß Standard 21.4.1 p6 die Ungültigmachung von Iteratoren / Referenzen nur zulässig ist

- als Argument für eine Standardbibliotheksfunktion, die einen Verweis auf non-const basic_string als Argument verwendet.

- Aufrufen von Nicht-Konstanten-Elementfunktionen, außer Operator [], an, vorne, hinten, Anfang, Anfang, Ende und Wiedergabe.

Für eine COW-Zeichenfolge würde das Aufrufen von non-const operator[]das Erstellen einer Kopie (und das Ungültigmachen von Verweisen) erfordern, was im obigen Absatz nicht zulässig ist. Daher ist es in C ++ 11 nicht mehr legal, eine COW-Zeichenfolge zu haben.

Die Antworten von Dave S und gbjbaanb sind richtig . (Und Luc Dantons ist auch richtig, obwohl es eher ein Nebeneffekt des Verbots von COW-Strings ist als die ursprüngliche Regel, die es verbietet.)

Aber um einige Verwirrung zu beseitigen, werde ich eine weitere Darstellung hinzufügen. Verschiedene Kommentare verweisen auf einen meiner Kommentare zum GCC-Bugzilla, der das folgende Beispiel enthält:

std::string s("str");
const char* p = s.data();
{
    std::string s2(s);
    (void) s[0];
}
std::cout << *p << '\n';  // p is dangling

In diesem Beispiel soll gezeigt werden, warum die COW-Zeichenfolge (Reference Counted) von GCC in C ++ 11 nicht gültig ist. Der C ++ 11-Standard erfordert, dass dieser Code ordnungsgemäß funktioniert. Nichts im Code erlaubt pes, das in C ++ 11 ungültig zu machen.

Mit GCC alten Referenzzählung std::stringImplementierung hat , dass Code nicht definiertes Verhalten, da p wird für ungültig erklärt, zu einem baumelnden Zeiger. (Was passiert ist, dass, wenn es erstellt s2wird, es die Daten mit teilt s, aber um eine nicht konstante Referenz über zu erhalten, s[0]müssen die Daten nicht freigegeben werden, ebenso swie eine "Kopie beim Schreiben", da die Referenz s[0]möglicherweise zum Schreiben verwendet werden könnte s, und dann s2geht außerhalb des Gültigkeitsbereichs, Zerstörung des Arrays, auf das durch gezeigt wird p).

Der C ++ 03-Standard erlaubt dieses Verhalten explizit in 21.3 [lib.basic.string] p5, wo er besagt, dass nach einem Aufruf data()des ersten Aufrufs an operator[]()Zeiger, Referenzen und Iteratoren ungültig werden können. Die COW-Zeichenfolge von GCC war also eine gültige C ++ 03-Implementierung.

Der C ++ 11-Standard erlaubt dieses Verhalten nicht mehr , da kein Aufruf von operator[]()Zeigern, Referenzen oder Iteratoren ungültig machen kann, unabhängig davon, ob sie einem Aufruf von folgen data().

Das obige Beispiel muss also in C ++ 11 funktionieren, funktioniert jedoch nicht mit der Art der COW-Zeichenfolge von libstdc ++. Daher ist diese Art der COW-Zeichenfolge in C ++ 11 nicht zulässig.

CoW ist ein akzeptabler Mechanismus, um schnellere Strings zu erstellen ... aber ...

Dadurch wird Multithreading-Code langsamer (all diese Sperren, um zu überprüfen, ob Sie der einzige sind, der die Leistung beeinträchtigt, wenn viele Zeichenfolgen verwendet werden). Dies war der Hauptgrund, warum CoW vor Jahren getötet wurde.

Die anderen Gründe sind, dass der []Operator Ihnen die Zeichenfolgendaten zurückgibt, ohne dass Sie eine Zeichenfolge überschreiben müssen, von der jemand anderes erwartet, dass sie sich nicht ändert. Gleiches gilt für c_str()und data().

Laut Quick Google ist das Multithreading im Grunde der Grund, warum es effektiv nicht zugelassen wurde (nicht explizit).

Der Vorschlag lautet:

Vorschlag

Wir schlagen vor, alle Iterator- und Elementzugriffsvorgänge sicher gleichzeitig ausführbar zu machen.

Wir erhöhen die Stabilität von Operationen auch im sequentiellen Code.

Diese Änderung verbietet effektiv Copy-on-Write-Implementierungen.

gefolgt von

Der größte potenzielle Leistungsverlust aufgrund einer Abkehr von Copy-on-Write-Implementierungen ist der erhöhte Speicherverbrauch für Anwendungen mit sehr großen, meist lesbaren Zeichenfolgen. Wir glauben jedoch, dass Seile für diese Anwendungen eine bessere technische Lösung darstellen, und empfehlen, einen Seilvorschlag für die Aufnahme in die Bibliothek TR2 in Betracht zu ziehen.

Seile sind Teil von STLPort und SGIs STL.

Ab 21.4.2 basic_string Konstruktoren und Zuweisungsoperatoren [string.cons]

basic_string(const basic_string<charT,traits,Allocator>& str);

[...]

2 Effekte : Konstruiert ein Klassenobjekt basic_stringwie in Tabelle 64 angegeben. [...]

Tabelle 64 dokumentiert hilfreich, dass nach der Erstellung eines Objekts über diesen (Kopier-) Konstruktor folgender this->data()Wert vorliegt:

zeigt auf das erste Element einer zugewiesenen Kopie des Arrays, auf dessen erstes Element str.data () zeigt

Es gibt ähnliche Anforderungen für andere ähnliche Konstruktoren.

Da jetzt garantiert ist, dass Zeichenfolgen zusammenhängend gespeichert werden und Sie jetzt einen Zeiger auf den internen Speicher einer Zeichenfolge nehmen dürfen (dh & str [0] funktioniert wie bei einem Array), ist es nicht möglich, eine nützliche COW zu erstellen Implementierung. Sie müssten eine Kopie für viel zu viele Dinge machen. Selbst wenn nur operator[]oder begin()eine nicht konstante Zeichenfolge verwendet wird, ist eine Kopie erforderlich.

Ist COW basic_stringin C ++ 11 und höher verboten?

Hinsichtlich

” Bin ich richtig, dass C ++ 11 keine COW-basierten Implementierungen von zulässt std::string?

Ja.

Hinsichtlich

“ Wenn ja, wird diese Einschränkung ausdrücklich irgendwo in dem neuen Standard angegeben (wo)?

Fast direkt durch Anforderungen konstanter Komplexität für eine Reihe von Operationen, die ein O ( n ) physisches Kopieren der Zeichenfolgendaten in einer COW-Implementierungerfordern würden.

Zum Beispiel für die Mitgliedsfunktionen

auto operator[](size_type pos) const -> const_reference;
auto operator[](size_type pos) -> reference;

… Was in einer COW-Implementierung ¹ sowohl das Kopieren von Zeichenfolgendaten auslösen würde, um die Freigabe des Zeichenfolgenwerts aufzuheben, erfordert der C ++ 11-Standard

“ Komplexität: konstante Zeit.

… Was ein solches Kopieren von Daten und damit COW ausschließt.

C ++ 03 unterstützt COW Implementierungen nicht diese ständigen Komplexitätsanforderungen haben, und durch unter bestimmten restriktiven Bedingungen, so dass Anrufe operator[](), at(), begin(), rbegin(), end(), oderrend() ungültig zu machen , Referenzen, Zeiger und Iteratoren auf die Zeichenfolge Posten beziehen, dh auf möglicherweise incur a Kopieren von COW-Daten. Diese Unterstützung wurde in C ++ 11 entfernt.

Ist COW auch über die C ++ 11-Ungültigkeitsregeln verboten?

In einer anderen Antwort, die zum Zeitpunkt des Schreibens als Lösung ausgewählt wurde und die stark positiv bewertet und daher anscheinend geglaubt wird, wird dies behauptet

” Für eine COW-Zeichenfolge const operator[]würde das Aufrufen von non- das Erstellen einer Kopie (und das Ungültigmachen von Referenzen) erfordern, was im obigen [zitierten] Absatz [C ++ 11 §21.4.1 / 6] nicht zulässig ist. Daher ist es in C ++ 11 nicht mehr legal, eine COW-Zeichenfolge zu haben.

Diese Behauptung ist in zweierlei Hinsicht falsch und irreführend:

• Es zeigt fälschlicherweise an, dass nur die Nicht- constItem-Accessoren eine COW-Datenkopie auslösen müssen.
  Aber auch die constElementzugriffsberechtigten müssen das Kopieren von Daten auslösen, da sie es dem Clientcode ermöglichen, Referenzen oder Zeiger zu bilden, die (in C ++ 11) später nicht über die Vorgänge ungültig gemacht werden dürfen, die das Kopieren von COW-Daten auslösen können.
• Es wird fälschlicherweise davon ausgegangen, dass das Kopieren von COW-Daten zu einer Ungültigmachung der Referenz führen kann.
  Bei einer korrekten Implementierung erfolgt das Kopieren von COW-Daten, wobei die Freigabe des Zeichenfolgenwerts aufgehoben wird, zu einem Zeitpunkt, bevor Referenzen vorhanden sind, die ungültig gemacht werden können.

Um zu sehen, wie eine korrekte C ++ 11 COW-Implementierung von basic_stringfunktionieren würde, wenn die O (1) -Anforderungen, die dies ungültig machen, ignoriert werden, stellen Sie sich eine Implementierung vor, bei der eine Zeichenfolge zwischen Eigentumsrichtlinien wechseln kann. Eine Zeichenfolgeninstanz beginnt mit der Richtlinie Sharable. Wenn diese Richtlinie aktiv ist, können keine externen Elementreferenzen vorhanden sein. Die Instanz kann zu einer eindeutigen Richtlinie übergehen und muss dies tun, wenn möglicherweise eine Elementreferenz erstellt wird, z. B. bei einem Aufruf von.c_str() (zumindest, wenn dadurch ein Zeiger auf den internen Puffer erzeugt wird). Im allgemeinen Fall, dass mehrere Instanzen das Eigentum an dem Wert teilen, müssen die Zeichenfolgendaten kopiert werden. Nach diesem Übergang zur Richtlinie "Eindeutig" kann die Instanz nur durch einen Vorgang, der alle Verweise ungültig macht, z. B. die Zuweisung, wieder zu "Freigabefähig" zurückkehren.

Obwohl die Schlussfolgerung dieser Antwort, dass COW-Zeichenfolgen ausgeschlossen sind, richtig ist, ist die angebotene Argumentation falsch und stark irreführend.

Ich vermute, die Ursache für dieses Missverständnis ist ein nicht normativer Hinweis in Anhang C von C ++ 11:

Änderung : basic_stringAnforderungen erlauben keine Zeichenfolgen mit Referenzzählung mehr.
Begründung: Die Invalidierung unterscheidet sich geringfügig mit Zeichenfolgen mit Referenzzählung. Diese Änderung reguliert das Verhalten für diesen internationalen Standard.
Auswirkung auf die ursprüngliche Funktion: Gültiger C ++ 2003-Code kann in dieser internationalen Norm anders ausgeführt werden

Hier erklärt die Begründung den Hauptgrund, warum man sich entschied, die spezielle COW-Unterstützung für C ++ 03 zu entfernen. Diese Begründung, das Warum , ist nicht, wie der Standard die COW-Implementierung effektiv verbietet. Der Standard verbietet COW über die O (1) -Anforderungen.

Kurz gesagt, die C ++ 11-Ungültigkeitsregeln schließen eine COW-Implementierung von nicht aus std::basic_string. Sie schließen jedoch eine einigermaßen effiziente, uneingeschränkte COW-Implementierung im C ++ 03-Stil aus, wie sie in mindestens einer der Standardbibliotheksimplementierungen von g ++ enthalten ist. Die spezielle COW-Unterstützung für C ++ 03 ermöglichte eine praktische Effizienz, insbesondere unter Verwendung von constElementzugriffsmethoden, auf Kosten subtiler, komplexer Regeln für die Ungültigmachung:

” Verweise, Zeiger und Iteratoren, die sich auf die Elemente einer basic_stringSequenz beziehen, können durch die folgenden Verwendungen dieses basic_stringObjekts ungültig gemacht werden :
- Als Argument für Nichtmitgliedsfunktionen swap()(21.3.7.8), operator>>()(21.3.7.9) und getline()(21.3. 7.9).
- Als Argument für basic_string::swap().
- Anruf- data()und c_str()Mitgliedsfunktionen.
- Aufruf nicht constFunktionen Mitglied, außer operator[](), at(), begin(), rbegin(), end(), und rend().
- Im Anschluss an einen der oben genannten Verwendungen außer den Formen insert()und erase()das Iteratoren zurück, der erste Anruf nicht constMitgliederfunktionen operator[](), at(), begin(), rbegin(),end()oder rend().

Diese Regeln sind so komplex und subtil, dass ich bezweifle, dass viele Programmierer, wenn überhaupt, eine genaue Zusammenfassung geben könnten. Ich könnte nicht.

Was ist, wenn O (1) -Anforderungen nicht berücksichtigt werden?

Wenn die konstanten operator[]Zeitanforderungen für C ++ 11 für z. B. nicht berücksichtigt werden, ist COW for basic_stringmöglicherweise technisch machbar, aber schwierig zu implementieren.

Zu den Vorgängen, die auf den Inhalt einer Zeichenfolge zugreifen können, ohne dass COW-Daten kopiert werden müssen, gehören:

• Verkettung über +.
• Ausgabe über <<.
• Verwenden eines basic_stringals Argument für Standardbibliotheksfunktionen.

Letzteres, weil die Standardbibliothek sich auf implementierungsspezifische Kenntnisse und Konstrukte stützen darf.

Zusätzlich könnte eine Implementierung verschiedene nicht standardmäßige Funktionen für den Zugriff auf Zeichenfolgeninhalte bieten, ohne das Kopieren von COW-Daten auszulösen.

Ein Hauptkomplikationsfaktor ist, dass in C ++ 11 der Elementzugriff das basic_stringKopieren von Daten auslösen muss (Aufheben der Freigabe der Zeichenfolgendaten), jedoch nicht ausgelöst werden muss , z. B. C ++ 11 §21.4.5 / 3 „ Throws: Nothing“. Daher kann keine normale dynamische Zuordnung verwendet werden, um einen neuen Puffer für das Kopieren von COW-Daten zu erstellen. Eine Möglichkeit, dies zu umgehen, besteht darin, einen speziellen Heap zu verwenden, in dem Speicher reserviert werden kann, ohne tatsächlich zugewiesen zu werden, und dann den erforderlichen Betrag für jede logische Referenz auf einen Zeichenfolgenwert zu reservieren . Das Reservieren und Aufheben der Reservierung in einem solchen Haufen kann eine konstante Zeit sein, O (1), und das Zuweisen des Betrags, den man bereits reserviert hat, kann seinnoexcept. Um die Anforderungen des Standards zu erfüllen, scheint es bei diesem Ansatz einen solchen speziellen reservierungsbasierten Heap pro eindeutigem Allokator zu geben.

^{Hinweise:
¹ Der constElementzugriffsauslöser löst eine COW-Datenkopie aus, da der Clientcode einen Verweis oder Zeiger auf die Daten erhalten kann, die durch eine spätere Datenkopie, die beispielsweise vom Nicht- constArtikelzugriffsgeber ausgelöst wird, nicht ungültig werden dürfen .}

Ich habe mich immer über unveränderliche Kühe gewundert: Sobald eine Kuh geschaffen wurde, konnte ich nur durch Zuweisung von einer anderen Kuh geändert werden, daher wird sie dem Standard entsprechen.

Ich hatte heute Zeit, es für einen einfachen Vergleichstest zu versuchen: eine Karte der Größe N, die mit einer Zeichenfolge / Kuh verschlüsselt ist, wobei jeder Knoten eine Reihe aller Zeichenfolgen in der Karte enthält (wir haben eine NxN-Anzahl von Objekten).

Mit Strings mit einer Größe von ~ 300 Bytes und N = 2000 Kühen sind die Kühe etwas schneller und verbrauchen fast eine Größenordnung weniger Speicher. Siehe unten, Größen sind in kbs angegeben, Lauf b ist mit Kühen.

~/icow$ ./tst 2000
preparation a
run
done a: time-delta=6 mem-delta=1563276
preparation b
run
done a: time-delta=3 mem-delta=186384