ich frage mich gerade, wie std::string seinen Speicher organisiert.

{
   unsigned char* char_ptr = foo();
   std::string s( char_ptr, size );
}

Ich habe einen großen C-String von irgendwo bekommen und lege nun die std::string Variable auf dem Stack an. Was passiert dann intern? Wird der Arrayinhalt aus char_ptr auf den Stack kopiert? Das könnte unter Umständen schnell zuviel werden, legt der Speicher auf dem Heap dafür an? Oder - das Beispiel ist nicht ganz richtig - für std::string müßte dies ein const char sein. Fungiert der nur als Referenz und benutzt den Inhalt des Pointers und holt sich erst Speicher, wenn er was verändert hat?

Hängt denn die Integrität von s an char_ptr?

danke

Natürlich möglich das intern mit shared strings gearbeitet wird. Also bei string1 = string2 noch nichts kopiert wird, solange keiner der beiden geändert wird. Aber das ist eben nicht im Standard definiert und so kann jeder Compilerhersteller das so handhaben wie er möchte.

Das trifft aber nur zu, wenn wir string-Objekte kopieren - da sich Quelle und Ziel über eine durch die Implementation definierte Schnittstelle einig sind, über die Schreibvorgänge erfolgen, kann man darüber COW realisieren. Das ist umgekehrt unmöglich, wenn die Quelle ein einfacher Zeiger ist, denn es gibt über keine Möglichkeit, Schreibvorgänge auf beliebigen Objekte zu überwachen.

Fellhuhn schrieb:

Natürlich möglich das intern mit shared strings gearbeitet wird. Also bei string1 = string2 noch nichts kopiert wird, solange keiner der beiden geändert wird. Aber das ist eben nicht im Standard definiert und so kann jeder Compilerhersteller das so handhaben wie er möchte.

Das trifft aber nur zu, wenn wir string-Objekte kopieren - da sich Quelle und Ziel über eine durch die Implementation definierte Schnittstelle einig sind, über die Schreibvorgänge erfolgen, kann man darüber COW realisieren. Das ist umgekehrt unmöglich, wenn die Quelle ein einfacher Zeiger ist, denn es gibt über keine Möglichkeit, Schreibvorgänge auf beliebigen Objekte zu überwachen.

Nur nebenbei, weil COW im Zusammenhang mit std::string erwähnt wurde...

COW mit std::string ist zwar möglich, aber es zahlt sich kaum aus. Der Grund ist dass man den String an so wahnsinnig vielen Stellen kopieren müsste. Beispiel:

std::string s1 = "sepp";
std::string s2 = s1; // s2 hat keine eigene kopie
std::string const& s2c = s2;

char c = s2[1]; // hier muss schon kopiert werden
char c2 = s2c[1]; // sogar hier müsste man genaugenommen kopieren
s2.begin(); // hier sowieso
s2c.begin(); // hier ... nicht unbedingt, ist aber auch nicht ganz klar

Der Grund (einer der Gründe) warum man da überall kopieren muss/müsste ist einfach dass der Standard es dem operator [] nicht erlaubt ein Proxy-Objekt zurückzugeben, sondern hier eine Referenz verlangt. Da im Fall "c = s2[1]" der "non-const" Overload von operator [] verwendet wird bleibt dem string sowieso keine andere Wahl als zu kopieren.

Aber selbst wenn der const Overload von [] aufgerufen wird: C++ erlaubt ausdrücklich das wegcasten von const mit const_cast wenn sichergestellt ist dass das Objekt nicht konst konstruiert wurde. Bei std::string ist das sichergestellt - zumindest solange der std::string selbst als mutable angelegt wurde, also dürfte man ohne weiteres die über "operator [] const" erhaltene Referenz auf non-const casten. Und damit den String modifizieren. Im Standard steht AFAIK auch nicht dass für Referenzen auf Elemente eines std::strings diesbezüglich spezielle Regeln gelten würden, also müsste die std::string Implementierung damit rechnen.

---

Ein COW std::string ist also möglich, aber der einzige Fall wo ich Chancen sehe dass es Vorteile bringt ist wenn Strings oft rumkopiert werden ohne sonst auch nur irgendwie angefasst zu werden (OK, Grösse Abfragen ginge noch, aber praktisch alles andere würde eine Kopie erzwingen, inklusive eben dem reinen "auslesen" des Strings). Einige wenige Anwendungen würden davon massiv profitieren, aber im allgemeinen denke ich würde es kaum was bringen. Da erwarte ich mir z.B. von move-semantics schon viel mehr

---

std::string ist IMO eine ganz gute "StringBuilder" Klasse, aber als String-Klasse ein totaler Reinfall.