ich habe eine Frgae zur Verwendung der std::stringstream klasse aus dem C++ Standard.

Ich stelle einen umfangreichen stringstream zusammen (1 MB) und möchte auf den darin enthaltenen std:string zugreifen, da ich eine Library verwende die ein std::string Objekt haben möchte.

Mit der Methode str() des Streams wird jedoch eine Kopie des internen std::string Objekts erstellt und damit noch einmal der gleiche Speicher alokiert. Diese Resourcen-Verschwendung möchte ich umgehen.

Ich habe bisher keine offizielle Möglichkeit gefunden auf das string-Objekt zuzugreifen.

Kennt sich jemand mit diesem Thema aus ?

Danke.

Infos zu RVO:
http://en.wikipedia.org/wiki/Return_value_optimization

Von MS gibts da auch einen RVO-Artikel:
http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx

Ich habe bisher keine offizielle Möglichkeit gefunden auf das string-Objekt zuzugreifen.

Dazu muß ich noch mal was speziell anmerken: zur Objektorientierung gehört auch Datenkapselung. Und das was du forderst, widerspricht der Datenkapselung. Es ist somit richtig das es keine direkten Zugriffsmöglichkeiten gibt und "nur" eine Kopie zurück gegeben wird, wenn man an die Rohdaten will.

... also so wie ich das unter der Speicherauslastung im Taskmanager gesehen habe wird der Speicher neu alokiert ... es müsste mit str() ja auch der Kopierkonstruktor des std::string Objekts aufgerufen werden ...

der Kommentar mit der Kapselung ist natürlich richtig, aber bei den anderen Streamarten werden ja auch vorhandene Datenquellen in den stream eingebettet ...
bei stringstream ist das jedoch nicht möglich, da dem Konstruktor eine Referenz auf std::string übergeben werden kann, aber intern trotzdem eine Kopie des string-Objekts erstellt wird ...

Kennt sich jemand mit der boost-library aus ? ... gibt es dort etwas brauchbares, das dieses problem gelöst hat ?

Ich denke nicht, das RVO in meinem beschriebenen Fall angewendet wird... das std::string objekt hat doch eher eine kleine größe und beinhaltet einen pointer, an dem der alokierte Speicher hängt ... RVO wird doch nur bei großen Objekten einer Klasse verwendet ... oder nicht ?

... also so wie ich das unter der Speicherauslastung im Taskmanager gesehen habe wird der Speicher neu alokiert

Nur dass der Taskmanager dir nicht direkt wieviel Speicher dein Programm wirklich braucht und noch weniger, was da tatsächlich so viel Speicher verbraucht - er kann dir nur erzählen was dein Betriebssystem den Programm an Speicher zugewiesen hat, und das ist bei weitem nicht das selbe.

Es steht zwar im Standard drin, das formal eine Kopie zurück gegeben wird (was auch sinnvoll ist, weil man den String nunmal nicht direkt manipulieren darf). Ein moderner Compiler kann aber meistens RVO anwenden und so Kopien vermeiden, wenn möglich und das Ergebnis nicht ungültig macht. Und RVO ist auch im Standard definiert und nicht illegal!

RVO könnte hier aber relativ schwierig werden; genauer gesagt ist selbst bei Anwendung von RVO noch eine Konstruktion notwendig. Falls der std::stringstream intern einen std::string speichert, muss er diesen kopieren, da es sich nicht um ein temporäres Objekt handelt. Ansonsten muss ein neuer std::string konstruiert werden. Was wegoptimiert werden kann, ist die unnötige Kopie beim Rückgabewert oder bei der Initialisierung.

pro_develop schrieb:

RVO wird doch nur bei großen Objekten einer Klasse verwendet ... oder nicht ?

Mit Grösse hat Return Value Optimization erstmal nichts zu tun. RVO wird oft angewandt, wenn ein temporäres oder funktions-lokales (NRVO) Objekt zurückgegeben wird und die Kopie offensichtlich unnötig ist.

Eine mögliche Lösung für dein Problem: Du kannst den std::string zuerst mit reserve() vorbereiten und anschliessend nach und nach per append() direkt füllen. Dann sparst du dir einen Schritt, nämlich die grosse Kopie von std::stringstream nach std::string . Die kleinen Kopien werden jetzt halt mit append() statt operator<< vollzogen.

Übrigens ist es wahrscheinlich, dass bei der Übergabe an die Bibliotheksfunktion so oder eine Kopie erstellt werden muss. Aber falls die Funktion wirklich für grosse Strings konzipiert ist, warum arbeitet sie mit Objekten? Da wäre ein Zeiger-Herumreichen, im Optimalfall sogar mit Smart Pointers, weitaus günstiger.

Edit: Denkfehler, der sich im Nachhinein als falsch herausstellte.

okay ... und mit welchen tools bzw. librarys könnte ich das noch besser untersuchen ?

... und stimmst du mir nicht bei der Antwort an Artchi zu ?

@Artchi

Ich denke nicht, das RVO in meinem beschriebenen Fall angewendet wird... das std::string objekt hat doch eher eine kleine größe und beinhaltet einen pointer, an dem der alokierte Speicher hängt ... RVO wird doch nur bei großen Objekten einer Klasse verwendet ... oder nicht ?

Dann wird der string erst bei Aufruf von str() erzeugt.

So wie ich pro_develop verstanden habe, ist das genau sein Problem. Ob man von einem std::string oder char* eine Kopie erstellt, spielt schlussendlich keine so grosse Rolle. Es braucht beides Speicher und Rechenzeit, mit denen er sparsam umgehen wollte.

Braunstein schrieb:

Das kann dann natürlich optimiert werden.

Optimiert werden können auch hier wieder nur unnötige temporäre Kopien.

std::stringstream Stream;      // mit 1 MByte füllen
DoSomething(Stream.str());     // kopiert mindestens einmal 1 MByte

Habe deine umfangreiche Antwort natürlich nicht übersehen

Ich habe mich auch bei den letzten Antworten falsch ausgedrückt ... ich meinte, dass RVO nur bei großen Objekten einer Klasse als Rückgabewert einen effektiven Nutzen haben dürfte... und dass ich nicht glaube, dass die Umsetzung von RVO so komplex ist, dass auch dynamisch alokierte Objekte von RVO gehandelt werden ....

Ich verstehe auch einfach nicht das Prinzip, nach dem der C++ Standard die stringstreams umsetzt ... bei einer Datei oder den E/A-Geräten kann ich doch auch direkt etwas auf dem Bildschirm dazwischen ausgeben ... oder wenn ich auf die datei zugreifen möchte, dann muss ich doch auch nicht erst eine kopie erstellen ... ?

Das mit der Datenkapselung ist schon richtig, aber es könnte doch wenigstens einen offiziellen Weg geben, um an die Adresse des internen string-Objekts zu gelangen um ggf. Zugriff auf die eigentlichen Rohdaten zu bekommen.

Ich finde das einfach nicht durchgängig von der Umsetzung her ... gibt es bei dem C++ Gremium, das den Standard festlegt, soetwas wie ein Verbesserungsvorschlagswesen ? Hat da jemand Kontakte ?

Ich dachte das ist nur in std::strstream ein char Array ...

In einem Artikel hatte ich gelesen, dass der Standard ein std::string Objekt für std::stringstream verwendet ...

Ist die Info in dem Artikel etwa falsch ???

ofstream f("datei.txt");
f << "Hallo"; // landet im Stream-Puffer, ein gekapselter Speicherblock
f.flush(); // eine Kopie des Stream-Puffers landet im Dateisystem (z.B. Festplatte)

Bei allen Outputstreams schiebst du Daten rein, und die werden am Ende irgendwo als Kopie landen müssen. Gerade wegen der Kopiererei sind die meisten Streams gepuffert! Und ohne Puffer wäre es wohl noch langsamer, weil dann jedes Byte einzeln kopiert werden müsste, anstatt der effizienteren blockweisen Kopie (so groß wie der Puffer halt).

Selbst die Ausgabe mit cout bedingt eine Kopie der Daten auf dem Bildschirmspeicher oder Terminal oder wie auch immer. Wenn durch flush() was in der Konsole oder Festplatte erscheint, ist es vergleichbar mit dem str() .

Das die Streams einen Direktzugriff erlauben, kann ich nicht erkennen. Kannst du vielleicht eine Methode vom fstream nennen?

Zu dem Gremium: das ist die WG21 Group. Und natürlich kann jeder dort seine Vorschläge einreichen (das Gremium bittet sogar darum!). Du kannst sogar an den Meetings persönlich als Zuschauer teilnehmen, die freuen sich wenn es Interessenten gibt. Eine Anlaufstelle kann die Newsgroup news://comp.lang.c++.moderated sein, da lesen und schreiben die meisten aus dem Gremium mit.
Tip: http://magazin.c-plusplus.net/artikel/Der CPlusPlus-Standardisierungs-Prozess

Danke für deinen Lösungsvorschlag

... da hab ich zu schnell auf "senden" gedrückt ... ich wollte doch noch auf deinen Lösungsvorschlag eingehen ...

... wenn ich zwischen dem stream und dem string objekt häppchenweise kopiere, dann habe ich doch aber das Problem mit dem allokierten Speicher nicht umgangen ??? ...

wenn meine Datei 100 MB groß wird, dann müsste ich doch mit string.reserve() die ganzen 100 MB allokieren ... oder wie hast du das gemeint ?

und der stream verringert ja auch nicht automatisch seine Größe, wenn ich in kleinen Stücken daraus lese ... ich könnte den stream doch erst zum Schluß dealokieren ... oder ?

du hast nicht verstanden wie ich das meine ... ich versuch es noch einmal zu erklären ...

wenn du einen File-Stream erzeugst, dann gibst du eine vorhandene, greifbare Datenquelle, also die auf der Platte vorhandene Datei an ... auf diese Rohdaten in der Datei kannst du auch auf anderen Wegen zugreifen ...

Bei den String-Streams kannst du eine vorhandene Datenquelle angeben, auf die ein freier Zugriff existiert ... es wird jedoch intern eine Kopie erstellt und damit geht der Zugriff auf die vom Stream bearbeiteten Daten verloren ... im Gegensatz zu einer Datei ...

@pumuckl:

okay ... und mit welchen tools bzw. librarys könnte ich das noch besser untersuchen ?

Die Tools heißen allgemein Profiler, mit denen kannst du Performance- und Ressourcenverbrauch untersuchen.

pro_develop! Warum benutzt du denn stringstream ? Wenn du problemlos string nutzen kannst, war stringstream eh die falsche Klasse. Denn normalerweise erfüllen beide Klassen unterschiedliche Zwecke.

siehe Anfangsproblematik ... ich generiere einen Stream mit der zur Verfügung stehenden Formatierung der Daten und muss dann einer Bibliotheksmethode eine Referenz auf std::string übergeben ...

siehe Anfangsproblematik ... ich generiere einen Stream mit der zur Verfügung stehenden Formatierung der Daten und muss dann einer Bibliotheksmethode eine Referenz auf std::string übergeben ...

Aha! Also kannst du doch nichts mit string anfangen. Denn zum Formatieren ist string nicht fähig. D.h. du mußt mit einer nicht- string -Klasse erstmal eine Zeichenkette formatieren, richtig? Egal wie du das anstellst, du wirst string dafür nicht nutzen können.

Wie willst du also eine Kopie der formatierten Zeichnkette vermeiden?

Dir bleibt nichts anderes übrigig, als einen eigenen stringstream zu implementieren oder Algorithmen (freie Funktionen), und bei der Übergabe des Strings an den Ctor die Endgültige Größe zu kennen:

// PSEUDO CODE!

class stringstream
{
    std::string &sref; // entscheidender Punkt!

public:
    stringstream(std::string &s) : sref(s) {}

// I/O Operatoren........
};

// ==========================================

int main()
{
 std::string s(10000, ' '); // String wird 10.000 Zeichen enthalten

 stringstream st(s);
 // irgendwas formatieren...

 foo(s);  // fremde Funktion, die einen std::string fordert
}

Dann würden die Operatoren direkt den referenzierten String manipulieren. Und damit sich das ganze auch rentiert, darf in dem oberen Beispiel der String keine 10.000 Zeichen übersteigen, weil sonst schon eine Kopieraktion im string nötig wäre - die du eigentlich vermeiden willst.

Auch dürfen die Operatoren nur Zeichen im String manipulieren, aber keine zus. hinzufügen, da sonst eine Kopieraktion in string droht.

Also ohne Profiler würde ich da keinen Finger für krumm machen... weil sonst ist alles für die Katz gewesen.

ich hab doch nicht gesagt, dass ich etwas mit sring formatieren will ... ??? *verzweifel*

siehe Anfangsproblematik ... ich generiere einen Stream mit der zur Verfügung stehenden Formatierung der Daten und muss dann einer Bibliotheksmethode eine Referenz auf std::string übergeben ...

ich schreibe in einer Schleife in den stringstream ...

hugo << hex << var_a << endl;

und damit wächst der in std::stringstream enthaltene std::string kontinuierlich an bis er z.B. 100 MB groß ist ...

und dann möchte ich eine Library verwenden, die den std::string parst, ohne beim erzeugen des std::string Objekts eine Speicherbelgung von 200 MB zu benötigen ...