std::string und seine Zukunft bzgl. Unicode?

unter windows UCS-2, unter linux UCS-4.

also unicode...

Artchi

@otze! Ja, offiziell hat ISO-C++ einfach keinen Unicode-Support. Du kannst ja nirgends UTF-8, UTF-16 oder UTF-32 benutzen. Es gibt ja nur string und wstring, wobei wstring immerhin schon 16bit breite Zeichen erlaubt. Aber das war es ja letztendlich auch schon. Aber wie kann ich z.B. Strings zwischen diesen Typen konvertieren? Ich wüsste jetzt ehrlich gesagt nicht wie.

Bisher mußte ich mich mit dem Thema nicht beschäftigen, deshalb bin ich da auch nicht so fit drin. Ich bekomme halt auch immer in div. Mailinglisten und Library-Dikussionen mit, das immer an Unicode-Klassen gebastelt wird, weil das in ISO-C++ fehlt.

Ich habe mir jetzt aber mal folgenden Artikel reingezogen:
http://www.codeproject.com/string/cppstringguide1.asp?df=100&forumid=11258&exp=0&select=1063467

Anscheinend kann man sich zumindest unter NT-Systemen mit std::wstring behelfen, da NT-Systeme standardmäßig mit Unicode arbeiten. Und wstring ist laut Artikel auf diesen Systemen der richtige Kandidat. (deshalb nimmt die GDI+ auch keine single-byte-Strings an, hab mich immer gewundert wieso)

Meine Library soll aber portabel sein, und da wäre vielleicht ein Hinweis zu Linux und Unix nicht schlecht. Wie wird das da gelöst? Ist da auch wstring der richtige Kandidat?

das mit dem unicode support ist doch nur wichtig wenn man die strings manipulieren will.

Ringding

wstring ist wunderbar. Du musst dir halt nur Gedanken machen, wie du die Strings von der Außenwelt empfängst (lädst) und wie du sie in die Außenwelt schickst (speicherst). Hierfür nimmt man wohl in den meisten Fällen UTF-8.

wstring ist nicht wunderbar und hat auch keinen Unicode-Support. Das fängt damit an, dass das Transformationsformat nicht festgelegt ist. Unicode mapped Zeichen auf Zahlen, ein Transformationsformat Zahlen auf Bytefolgen. wstring kennt kein Transformationsformat und kommt daher nur mit naiven Encodings wie UCS-2 oder UCS-4 zurecht. Davon abgesehen, dass die fast nie verwendet werden, ist wohl auch nicht festgelegt, welches es denn nun ist, womit auch die Frage mit Portabilität gegessen ist... jeder Compiler kann es anders machen und macht es auch anders.

Es gibt wohl plattformabhängige "Lösungen", beispielsweise verwendet der VC++-Compiler das UTF-16, das heißt < insert ostasiatisches zeichen here > wird dann auch korrekt auf zwei wchar_t mit sizeof(wchar_t) = 2 gemapped, allerdings weiß der wstring nichts davon und daher kann man ihn nicht zu viel mehr verwenden, als einen String umherzukopieren oder auszugeben, wo nur sequentiell gelesen werden muss.

Wer ernsthaft mit Unicode arbeiten möchte, muss sich nach anderen String-Klassen umsehen, beispielsweise MFC::CString, java.lang.String, .Net::System::String, daran führt kein Weg vorbei.
Und hier noch ein von kingruedi geklauter Link: http://www.cl.cam.ac.uk/~mgk25/unicode.html

MFC::CString ist doch bestimmt TCHAR

Und auch nicht plattformunabhängig.
EDIT: TCHAR ist btw. wchar_t wenn man es entsprechend compiliert und der Witz ist halt, dass der CString weiss, wann zwei wchar_t nur ein Zeichen sind.

Und warum weiß das CString und wstring nicht?

wstring hat nur eine Methode, um das n-te wchar_t abzufragen und ist nicht für multibyte character sets ausgelegt. CString hat vermutlich eine Methode, um das n-te Zeichen zu suchen. Sicher weiß ich es jetzt zumindest bei java.lang.String und System::String, CString habe ich noch nicht benutzt.

Ringding

Aber IMHO ist UTF in der Anwendung das Letzte, was man braucht. Diese Multibytesequenzen machen die Sache doch nur unnötig kompliziert. Mit ucs-2 oder -4 hat jeder Character genau die gleiche Größe, und alles funktioniert genau wie mit string/char[]. Nur bei der Ein-/Ausgabe muss man halt irgendwas mit dem String anstellen.

Du hast nicht so wirklich die Wahl, du musst dich nach dem richten, was die Compilerbauer für wchar_t eingebaut haben. Man könnte allerdings nen basic_string<int32> verwenden, man braucht halt Möglichkeiten, für "nach außen" wieder zu konvertieren. Naja, toll ist das IMHO nicht.