spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Auch wenn dir das Kapitel mit den Zeigern sicherlich weiterhelfen wird, so solltest du trotzdem std::string verwenden. Sie wurde ja nicht ohne Grund entwickelt (und zum Standard erklärt):

• Speicherverwaltung
• Kopier- und Zuweisungsoperatoren
• uvm.

Darüber hinaus existiert die Methode const char* std::string::c_str() const, welche du nutzen solltest, wenn eine andere API einen CString (const char*) erwartet. Es besteht hier kein Grund, auf nackte CStrings zu setzen.

Grüße ... Heiko

Zitat von »bwbg«

Auch wenn dir das Kapitel mit den Zeigern sicherlich weiterhelfen wird, so solltest du trotzdem std::string verwenden. Sie wurde ja nicht ohne Grund entwickelt (und zum Standard erklärt):
SpeicherverwaltungKopier- und Zuweisungsoperatorenuvm.Darüber hinaus existiert die Methode const char* std::string::c_str() const, welche du nutzen solltest, wenn eine andere API einen CString (const char*) erwartet. Es besteht hier kein Grund, auf nackte CStrings zu setzen.

Grüße ... Heiko

Außer vielleicht, dass std::string-Objekte verdammt langsam sind. Die Klasse hätte wohl eher die Bezeichnung std::string_builder verdient.

Äh, wa? In welchen Momenten genau ist std::string denn langsam? Also ich meine in welcher praktischen Situation macht sich da Performance irgendwie bemerkbar?

Gibts da in der optimierten Fassung am Ende überhaupt einen Unterschied?

Nicht, dass das für den vorliegenden Anwendungsfall eine Rolle spielte. Die CPU langweilte sich selbst im Debug-Build ...

Natürlich kann die std::string-Objekte so langsam wie möglich verwenden, wenn man diese bei Funktionsaufrufen kopiert, statt per Referenz zu übergeben. CStrings wären jedoch genau so langsam, wenn man diese vor jedem Funktionsaufruf kopierte (Länge ermitteln, Speicher alloziieren, kopieren).

Ein String-Builder wäre wohl eher std::stringstream .

Grüße ... Heiko

Zitat von »bwbg«

Natürlich kann die std::string-Objekte so langsam wie möglich verwenden, wenn man diese bei Funktionsaufrufen kopiert, statt per Referenz zu übergeben. CStrings wären jedoch genau so langsam, wenn man diese vor jedem Funktionsaufruf kopierte (Länge ermitteln, Speicher alloziieren, kopieren).

Nein, das hat damit wirklich nichts zu tun... die std::strings sind bei sehr großen Zeichenketten ziemlich träge. Das liegt unteranderem daran, dass diese Klasse nicht ganz dem Konzept eines Strings entspricht. So sind Strings in jeder anderen Sprache Java, C#, D... anders aufgebaut. Ein String sollte sich selbst nämlich nicht manipulieren und verändern dürfen, sondern sollte immer einen konstanten nicht veränderbaren Wert haben. Anstatt den eigenen String zu verändern sollte nämlich ein neuer erzeugt werden. So aber liegen die Strings in C++ anderen Implementierungen andere sprachen sehr hinterher:
http://d-programming-language.org/cppstrings.html

In seinem Fall sollte das natürlich nicht von Nachteil sein, aber wenn man mal mit 2GB großen Zeichenketten zu tun haben sollte...

Sorry, aber 2GB große Zeichenketten zu verwenden kann einfach nicht performant sein. Da braucht man sich auch nicht wundern.

Musste mal nen 2GB Logfile checken. Da dass natürlich zu viele Zeilen waren, habe ich nen Parser geschrieben, der unwichtige Zeilen löscht und somit Schritt für Schritt die Datei gekürzt. Da war das nun wichtig. Da hat Laufzeit aber auch keine allzu große Rolle gespielt, da das ganze halt einmalig von mir eingesetzt wurde Ich denke auch, dass 2GB Strings nicht der Normalfall sind. Vor allem in diesem Beispiel ist der Hinweis quatsch. Und welche Implementierung eines Strings nun optimal ist kommt auch immer auf das Einsatzgebiet an. Wenn du nun mit deinem 2GB String arbeiten möchtest und in diesem ein paar Zeilen ändern möchtest ist es auch nicht besonders toll, wenn dein String erst wieder komplett neu erstellt wird. Geht aber erst mal um das Thema hier und da sollte er nun mal auf die String Klasse zurück greifen.

Arr. Ja meine Formulierung ist hier etwas unglücklich verlaufen, das gebe ich zu. Und es stimmt auch, dass es direkt für dieses Beispiel natürlich nicht relevant ist. Aber: das mit dem 2GB-String war nur ein Extrem-Beispiel, ich bin mir nämlich sicher, dass „string-manipulier-intensive“ Algorithmen mit einer anderen String-Implementierung spürbar schneller wären. Im D vs. C++-Benchmark jedenfalls waren D-Strings doppelt so schnell, was nicht unbedingt für den std::string spricht

Genau genommen kann man kein "D vs C++" durchführen, sondern nur Compiler und Laufzeitbibliotheken miteinander vergleichen. C++ ist ja nur die Sprache, Compiler gibt es viele.