std::string nach char* konvertieren
-
Icematix schrieb:
Ich hab es mit VC++ 2008/1010 schon oft so gemacht.
Das sollte man in seine coding styles aufnemen: Gutes Deisgn ist, wenns Icematix schon oft in VC++ 2008/2010 gemacht hat.
Einen char* benötigt man, um die dahinter liegende Zeichenkette zu manipulieren und dafür ist die string Klasse nicht konzipiert. Ich würde das nicht als gefährlich oder schlecht, sondern schon als einfach falsch bezeichnen. Wenn man irgendeine C-API benutzt und für die Ausgabe o.ä. einen string mal kopiert ist das kein Weltuntergang. Wenn diese Aufrufe so häufig vorkommen und ihr Anteil an der eigenltichen Aktion dominiert ist die Wahl der string Klasse einfach falsch. Dann sollte man über z.B. über vector<char> nachdenken.
-
Das sollte man in seine coding styles aufnemen: Gutes Deisgn ist, wenns Icematix schon oft in VC++ 2008/2010 gemacht hat.
Compilerspezifisches Gefrickel finde ich immer noch schöner als in Nutzcode mit new/delete rumzuhantieren sowie den Overhead des Kopierens auf sich zu nehmen.
Außerdem verlangt praktisch jede API-Funktion (in der WinAPI zb jede), die einen char* entgegennimmt auch gleich die Größe, dh. es wird nicht von einer Nullterminierung ausgegangen.
Unter der Haube hat die std::string Klasse übrigens erschreckende Ähnlichkeit mit std::vector<T>, ich würde nicht behaupten, dass die Stringklasse dafür nicht konzipiert ist.
Aber ich muss ganz ehrlich zugeben: In fast jedem Fall der mir bis jetzt untergekommen ist, in dem eine Funktion einen per char* gezeigten Buffer beschreibt, ist die Nutzung der Stringklasse sowieso überflüssig und man sollte auf einen std::vector zurückgreifen ...
-
Icematix schrieb:
Das sollte man in seine coding styles aufnemen: Gutes Deisgn ist, wenns Icematix schon oft in VC++ 2008/2010 gemacht hat.
Compilerspezifisches Gefrickel finde ich immer noch schöner als in Nutzcode mit new/delete rumzuhantieren sowie den Overhead des Kopierens auf sich zu nehmen.
Außerdem verlangt praktisch jede API-Funktion (in der WinAPI zb jede), die einen char* entgegennimmt auch gleich die Größe, dh. es wird nicht von einer Nullterminierung ausgegangen.
Amen. Code, play and pray.
-
Icematix schrieb:
...Overhead des Kopierens auf sich zu nehmen....
Nunja - in den Zeiten, in denen die meisten Menschen mit Java-Anwendungen zufrieden sind und Maschinen auf dem Tisch stehen haben, die locker eine Marsmission koordinieren könnten, verliert dieser Ansatz aus den 70ern ein wenig an Brisanz.
Gruß,
Simon2.
-
Was hast du denn genau vor, sudo? Es gibt andere Möglichkeiten, an die Zeichen eines strings zu kommen.
-
Nunja - in den Zeiten, in denen die meisten Menschen mit Java-Anwendungen zufrieden sind und Maschinen auf dem Tisch stehen haben, die locker eine Marsmission koordinieren könnten, verliert dieser Ansatz aus den 70ern ein wenig an Brisanz.
Würde ich nicht sagen
Unterschätze mal die ganze Kopiererei und das allozieren von Heapspeicher nicht.Ich habe mir für ein Projekt ein Pendant zu std::string geschrieben, der allerdings statischen Speicher hat, nichts extra am Heap anlegt.
Ergebnis: Höherer Speicherverbrauchen, stark reduzierte CPU-Auslastung.
Und ganz ehrlich: 100MB mehr RAM verbrauch stören mich bei 8GB RAM deutlich weniger als die 20% mehr CPU-Auslastung, die das Nutzen von std::string gekostet hatNa gut, war auch eine Anwendung die sehr viele Stringoperationen durchgeführt hat...
-
Hi,
ich glaube trotzdem, dass in 90% der Fälle
- das Kopieren kein Problem ist oder
- man an anderen Stellen besser optimieren kann (Programmstruktur optimieren!) oder
- eine bessere std::string-Implementierung Abhilfe schafft.Und in 98% der Fälle schaffen häßliche const-casts bzw. eine sehr rigide "Bloß-nicht-Kopieren"-Strategie mehr Probleme als sie lösen.... (gerade über einen kompletten Lebenszyklus einer Anwendung betrachtet).
Gruß,
Simon2.
-
Icematix schrieb:
Na gut, war auch eine Anwendung die sehr viele Stringoperationen durchgeführt hat...
Dafür ist auch nicht std::string, sondern die Streamklassen vorgesehen.
-
Ein guter Compiler wird doch sowieso erkennen, ob was kopiert werden muß.
-
Alles kann der auch nicht wegoptimieren.
Er möchte einer Funktionen einen Zeiger auf eine nicht konstante Zeichenkette übergeben. Das geht mit der std::string Klasse nicht, daher muss er den Inhalt woanders hinkopieren. Oder er muss sich direkt gegen std::string entscheiden. Es könnte (?) evtl. eine STL Implementierung zulassen, den Inhalt von string per std::move in einen vector zu schieben. Glaub/weiß ich aber nicht.
Wurde doch auch schon alles gesagt, in den meisten Fällen wird man vom Kopieren überhaupt nichts bemerken, wenn doch, dann mach anders.