Resourcenproblem mit std::stringstream
-
Artchi schrieb:
Shade Of Mine schrieb:
klingt ja stark als ob der op strstream suchen würde...
strstream ist meines Wissens deprecated. Also nicht gerade zukunftssicher. Aber selbst wenn, hilft das dem OP auch nicht weiter.
deprecated, ja.
aber warum hilft das denn nicht?strstream erlaubt die gewünschten formatierungen auf einem rohen puffer zu machen. somit habe ich die daten in dem stream und in dem "string" gleichzeitig ohne kopieren zu müssen...
-
Shade Of Mine schrieb:
Artchi schrieb:
Shade Of Mine schrieb:
klingt ja stark als ob der op strstream suchen würde...
strstream ist meines Wissens deprecated. Also nicht gerade zukunftssicher. Aber selbst wenn, hilft das dem OP auch nicht weiter.
deprecated, ja.
aber warum hilft das denn nicht?strstream erlaubt die gewünschten formatierungen auf einem rohen puffer zu machen. somit habe ich die daten in dem stream und in dem "string" gleichzeitig ohne kopieren zu müssen...
Aber die Library-Funktion, die der OP aufrufen will, will ein std::string-Objekt. D.h. er müsste diesen rohen Daten dem Ctor des string-Objekts übergeben... und dieses macht doch auch eine Kopie von diesen Rohdaten?!
Ich habe übrigens gesehen, das man mit
rdbuf()auch auf den Stringbuffer im Stringstream zugreifen kann.
Aber ist halt auch kein string-Objekt... auch hier ist eine Kopie nötig.Er wird um das Kopieren nicht rum kommen.
-
Artchi schrieb:
Aber die Library-Funktion, die der OP aufrufen will, will ein std::string-Objekt. D.h. er müsste diesen rohen Daten dem Ctor des string-Objekts übergeben... und dieses macht doch auch eine Kopie von diesen Rohdaten?!
Man kann dem streambuf von strstream einen bereits erstellten char-buffer zum draufrumschreiben übergeben. Also z.B. einen string nehmen, ihn genügend resizen, mittels <insert some evil nonstandard hack here> auf den drunterliegenden (nonconst!) char-array zugreifen und den an den strstream übergeben, damit der drauf rumschreibt.
Das wäre dann viel böse Magie um ein Speicherproblem zu behacken, von dem immernoch nicht sichergestellt ist ob es auch wirklich das Speicherproblem ist, wenn es denn überhaupt ein nennenswertes Problem dabei gibt.
-
OK, du meinst diese Funktion?
http://www.cplusplus.com/reference/iostream/stringbuf/setbuf/Gut, dann hat er jetzt seinem Stream diesen vorbereiteten Puffer übergeben. Wie geht er jetzt weiter vor, um eine Kopie (bei der Erstellung eines std::string-Objektes) zu vermeiden?
-
drückt ihm doch erstmal nen profiler rein.... bevor ihr hier so nen wind macht.
-
Artchi schrieb:
OK, du meinst diese Funktion?
http://www.cplusplus.com/reference/iostream/stringbuf/setbuf/Nein. Ich rede von strstream, nicht von stringstreams stringbuf. Dem Ctor von strstream kann ein char-array zum beackern übergeben werden - er erstellt sich dann kein eigenes.
It0101 schrieb:
drückt ihm doch erstmal nen profiler rein.... bevor ihr hier so nen wind macht.
Ist doch schon geschehen. Mehr als zigmal drauf hinweisen dass das Problem vielleicht garkeines ist können wir kaum
-
pumuckl schrieb:
It0101 schrieb:
drückt ihm doch erstmal nen profiler rein.... bevor ihr hier so nen wind macht.
Ist doch schon geschehen. Mehr als zigmal drauf hinweisen dass das Problem vielleicht garkeines ist können wir kaum
Vll? Oo
Er macht sich sorgen, weil er 1MB kopieren muss...
Ich weiß ja nicht, wie oft er das tut, aber wenn man nen paar 100Gbps kopieren kann, dann sollte 1MB nicht mal spürbar sein... Und wenns um eine Million Zeichen geht, gibts mit Sicherheit nen "richtigen" Flaschenhals^^bb
-
Alternativ kann der std::string auch sukzessiv aufgebaut werden, in dem nur Teile von std::stringstream eingelesen und an std::string angehangen werden. Das loest nicht dein Kopierproblem, doch der zusaetzliche Speicher wird auf die Groesse des auf einmal einzulesenden Blocks reduziert (theoretisch).
-
Danke für die vielen Tipps und Vorschläge
@Nexus: Du bist der Beste
heute mittag stand mir wohl jemand auf der Leitung ... jetzt hab ich verstanden, was du gemeint hattest mit dem Vorschlag über append() den std::string aufzubauen ... ich war irgendwie an der Stelle, wenn ich den Stream schon erstellt habe ... klar, wenn ich einen Stream lokal immer wieder erstelle und dann meine Daten damit formatiere, kann ich den String langsam mit append()zusammensetzen ... das ist die Lösung !
Ich bin aber trotzdem der Meinung, dass die Bibliothek an dieser Stelle keiner klaren Linie folgt, wenn in strstream der Speicher zugreifbar war, in der stringstream Template Klasse jedoch nicht mehr ... fstream arbeitet ja auch nicht auf einer temp. Kopie der Datei, damit die Daten nicht von einer anderen Stelle aus verändert werden können ...
Werde der WG21 mal eine Mail schreiben ...
-
jetzt hab ich verstanden, was du gemeint hattest mit dem Vorschlag über append()
Oh, der Vorschlag kam schon ... und warum hat das dann 4 Seiten gebraucht, bis es durchsickert ... *kopfschuettel*
-
pro_develop schrieb:
@Nexus: Du bist der Beste
Hehe, vielen Dank. Schön, dass dir mein Vorschlag geholfen hat!
@ Premature-Optimization-Fanatiker:
Es ist im Allgemeinen sicher nicht schlecht, nachzumessen, statt seine Urteile auf Vermutungen zu basieren. Wenn es aber offensichtlich ist, dass eine Möglichkeit, die weder viel Mehraufwand noch sonstige Probleme (schlechtere Wartbarkeit, hässliches Design oder Ähnliches) mit sich bringt, von der Performance her günstiger ist, dann sollte es doch gerechtfertigt sein, diese zu nutzen.
