A
VolkerH schrieb:
Dein Vergleich mit vector und string ist schon putzig, natürlich kann man es so sehen. Aber irgendwie klingt es bei Dir fast negativ.
Ist aber nicht so gemeint; das war eine nüchterne Feststellung. Ich begrüße die Existenz von std::string anstelle z.B. einer Spezialisierung wie std::vector<bool>, und die vorhandenen Komfortfunktionen sind IMHO knapp am Mindesten dessen, was eine Stringklasse bieten sollte. (Auch hier Einigkeit!) Ich weiß nicht, wo du bei dem Vergleich mit std::vector eine Herablassung gegen die STL-Designer herausliest, aber meine Absicht war so etwas jedenfalls nicht.
VolkerH schrieb:
Die Mehrheit der Programmierer würde auch nicht auf die Idee kommen, etwas anderes damit zu machen, als Zeichenketten mit eben den genannten Funktionen zu verwalten.
Klar. Und da std::[w]string so entworfen ist, daß es den Inhalt des Strings nicht weiter als bis zum terminierenden Nullzeichen interpretiert, kann man nützlicherweise beliebige Encodings darin unterbringen, solange man sich des jeweiligen Encodings bewußt bleibt.
VolkerH schrieb:
Bezogen auf Unicode ist die Unterstützung für die C++ Strings eher rudimentär, und die variable Länge muss irgendwie aufgefangen werden.
Das ist, wie gesagt, situationsabhängig - und der meiste stringverarbeitende Code kommt mit UTF-8 bzw. UTF-16 zurecht. Punkt meines Statements war, daß du mit std::wstring für UTF-16 kein bißchen besser dran bist als mit std::string für UTF-8.
(Was natürlich nichts daran ändert, daß die String-Typen in Delphi und C++Builder diese Aufgabe um Längen besser bewältigen.)
VolkerH schrieb:
Um beim Builder zu bleiben, wenn Du einen UTF8 Code in einen string schaufelst, und via c_str() wieder herausholst, stehen nur noch Fragezeichen da.
UnicodeString::UnicodeString(const char*) nimmt an, es erhalte einen String mit der Codepage 0 (der System-Codepage). Wie könnte der Konstruktor wissen, welche Codepage der String tatsächlich hat? Wenn du die Codepage bei der Umwandlung von STL-String nach VCL-String explizit angibst, geht es wunderbar:
std::string stl_string = "Heiz%F6lr%FCcksto%DFabd%E4mpfung";
// entweder sagen wir direkt, daß dies ein UTF-8-String ist...
String delphi_string = UTF8String (stl_string.c_str ());
// ... oder wir arbeiten einfach auch auf VCL-Seite mit einem UTF-8-String.
UTF8String utf8_string = stl_string.c_str ();
VolkerH schrieb:
Schaufelst Du ihn hingegen in einen wstring (da wir hier ja beim Builder- Thema sind, da gibt es für die Delphi- UTF- Klasse extra die Funktion w_str()), und dann via c_str wieder zurück in den UTF- String, bleibt der Text erhalten. Zumindest in der Regel.
Das liegt daran, daß die hierzulande gebräuchlichen Zeichen alle in UCS-2, also in den statischen 2-Byte-Zeichensatz passen. Anstelle sich damit zu begnügen, sollte man sich eher der Urheber von 7-Bit-ASCII erinnern, die Sparsamkeit und Praktikabilität höher bewerteten als das Bedürftnis von Nichtanglophonen nach Umlauten oder Akzenten. (Das ärgert mich bei jeder MD, die ich betitle, erneut.) Frage mal einen Chinesen oder sonst jemanden, dessen Schriftzeichen nicht alle in UCS-2 gepaßt haben.
VolkerH schrieb:
Du kannst der Maße (ich denke mehr als 80%) der C++ Entwickler gerne erklären, dass sie, wenn sie ein bisschen drumherum machen und programmieren, das ganze trotzdem in strings speichern könnten. Es interessiert die meisten nicht.
Wie du meinst.
Was tut aber der nicht wechselwillige C++-Programmierer, der UTF-8 und UTF-16 benutzen muß, wenn nicht die Strings verwenden oder auf C++0x warten?
