Welche Klasse haltet ihr für die beste? Welche sollte man wann verwenden?

Hallo Du,

kommt drauf an für was der String/CString sein soll? Müsstest das Problem schon mal etwas detaillierter darstellen.....

Aber... Vorteile von CString:
- es gibt genügend portable Implementationen außerhalb der MFC
- stärkere Performance-Garantien als std::string
- Bessere Interop mit anderen Bibliotheken / C-API's etc.

Nachteile:
- Templatisierung über char-typ erst ab VC7
- Der "böse Trick" für vararg-Argumente. Das betrifft aber nicht die CString-Klasse selbst, sondern "nur" gängigen Client-Code

CString ist referenzgezählt. Damit kann man guten Gewissens CString als Rückgabewert einsetzen. Mit GetBuffer/ReleaseBuffer machen Interop einfacher.

std::string kann referenzgezählt sein, muß aber nicht ¹⁾ std::string kann als NULL-terminierte Zeichenkette implementiert sein, muß aber nicht. Für interop kommt man mit std::vector<char> deutlich besser als mit std::string

^1) referenzgezählt ist nicht immer besser - aber wenn man es nicht weiß, ist man bei performancekritischen Schnittstellen ziemlich eingeschränkt^

das mit dem referenzgezählt habe ich allerdings nicht so ganz verstanden, was versteht man darunter?

Nach außen verhält sich der String "wie erwartet", intern wird aber das kopieren (was oftmals gar nicht nötig ist) geschieht erst wenn der String selbst wirklich verändert wird. Das hilft ungemein, "bequeme" Interfaces zu schaffen, ohne Effektivität zu verlieren.

Häufigster Fall: Wird ein CString als (By-Value-)Funktionsparameter oder als Return-Wert übergeben, wird keine Kopie erzeugt.

Beispiel:

CString CFoo::GetItemText() { return m_itemText; }
void CBar::SetName(CString s, bool appendSpace = false) 
{ 
  if (appendSpace) s += ' ';
  ...// was auch immer mit s geschehen soll
}

// ohne eine einzige Kopie:
bar.SetName(foo.GetItemText());

Referenzgezählte Objekte können in Multithreaded-Programmen allerdings bremsen, wenn die Referenzzähler häufig aus verschiedenen Threads rauf- und runtergezäht werden, und jedesmal ein Thread auf den anderen warten muß. Aber wenn man das weiß, kann man sein Programm halt dementsprechend anpassen...

d.h. du musst weniger schreiben wenn du cstring in einer ms umgebung benutzt

sobald du auf mehreren systemen arbeitest brauchst du zwingend den stl string, oder char pointer bzw. eine eigene klasse die den char pointer nach ansi standard kapselt (der stl string is auf vielen embedded systemen nich vorhanden)

bei den mainstream systemen (win mac linux) is der stl string die beste wahl

CString wurde zu einer Zeit entwickelt, als es die C++-Klasse string noch nicht im Standard gab. Prinzipiell sollte man immer std::string verwenden, da es alle notwendigen Funktionen bereit hält.

Kann man nicht so verallgemeinern. Wenn ein Programm schon "MFC-verseucht" ist dann sehe ich keinen Grund nicht CString zu benutzen. Die STL-Stringklasse finde ich nicht sonderlich gelungen. Man muss sich zuviele Sachen drum herum basteln (z.B. trim, replace etc.). CString gefällt mir von der "Bedienung" her schon besser. Bei neu gestarteten Projekten und wiederverwendbaren Klassen würde ich aber auch eher zum std::string tendieren und sie komplett MFC-frei halten.

komplett MFC-frei halten

Ich will dich ja nicht in die totalte Dunkelheit führen, Mastah, aber CString gibt es auch ohne MFC

(Wenn ich sehe, wie oft MFC-Unterstützung zu einem ATL- oder Consolen-Perojekt dazugefügt wird - und warum? "Na, wegen CString"....)

Wenn man MFC verwendet kann man auch CString verwenden. MS hat diese Klasse optimiert.
Will man auch andere Plattformen dann hat man hier sowieso nichts verloren da MFC nicht verwendung finden kann.

CString str = "Hallo!";

//irgendwas mit dem string machen, z.b. MessageBox(str)...

str = "Welt";

//Wieder irgendwas machen.

Darf man so immer wieder den Text ändern?

Ich habe noch eine Frage, und zwar ist das erlaubt, bzw. in ordnung:

CString str = "Hallo!";

//irgendwas mit dem string machen, z.b. MessageBox(str)...

str = "Welt";

//Wieder irgendwas machen.

Darf man so immer wieder den Text ändern?

natürlich.

Will man auch andere Plattformen dann hat man hier sowieso nichts verloren da MFC nicht verwendung finden kann.

Ha!

CString implementation based on basic_string

Google:CString clone

komplett MFC-frei halten

Ich will dich ja nicht in die totalte Dunkelheit führen, Mastah, aber CString gibt es auch ohne MFC

Ändert nichts an der Tatsache, dass du die MFC in meinen zukünftigen Projekten nicht mehr finden wirst. Und wenn ich die MFC nicht verwende dann verwende ich auch kein CString, da die Vorteile hinfällig werden.

da die Vorteile hinfällig werden

find ich nicht, aber ist vioelleicht geschmackssache (oder: welche Vorteile sind dir wichtig)

unix tom hat auch recht... std::string macht beim klassenexport per dll echte probleme