Ich habe das Gefühl, dass die Frage vor längerer Zeit auch schon mal aufgetaucht ist, aber nun da C++11 und Unicode mehr oder weniger einsatzbereit sind, möchte ich nochmals darauf zurückkommen.

Wenn man frei wählen kann, sollte man eher zu std::string oder zu std::wstring greifen (gilt auch für die zugehörigen Streams und anderen Objekte)? Mir ist bewusst, dass ich mit UTF-8 auch in einem std::string Unicode speichern kann, welche dann mehrere Chars beanspruchen. Aber warum sollte man dann überhaupt jemals zu std::wstring greifen? Gibt es irgend einen Grund dafür?

Derzeit tendiere ich zu std::wstring, weil .NET und Windows UTF-16 nutzen, was in der Regel gut in wchar_t passt (beim GCC auf Linux ist wchar_t aber scheinbar 32 Bit lang; Platzverschwendung ist mir aber egal). Was sollte man wählen, wenn man seine Applikation möglichst portabel halten will?

MfG

Mir ist bewusst, dass ich mit UTF-8 auch in einem std::string Unicode speichern kann, welche dann mehrere Chars beanspruchen.

Ist dir auch bewusst, dass das bei UTF-16 nicht anders ist? Unicode hat nämlich mehr als 2^16 verschiedene Zeichen.

/rant/ schrieb:

Aber warum sollte man dann überhaupt jemals zu std::wstring greifen? Gibt es irgend einen Grund dafür?

Nein

/rant/ schrieb:

Derzeit tendiere ich zu std::wstring, weil .NET und Windows UTF-16 nutzen, was in der Regel gut in wchar_t passt

Was hat dein Programm mit .NET zu tun?
Benutzt du viel die WinAPI oder wozu benötigst du UTF-16-oder-was-das-ist?
Was spricht dagegen, an entsprechenden Stellen zu konvertieren?
Was beinhalten die Strings überhaupt?

/rant/ schrieb:

(beim GCC auf Linux ist wchar_t aber scheinbar 32 Bit lang; Platzverschwendung ist mir aber egal). Was sollte man wählen, wenn man seine Applikation möglichst portabel halten will?

char / string / UTF-8

Natürlich hat man mit UTF-16 die gleiche "Problematik". Ein Zeichen muss nicht in 16 Bit passen. Das ist ja genau meine Frage: Warum hat man bei Java, .NET und diversen Betriebssystemen den Schritt gemacht und gesagt, wir nutzen UTF-16 und nicht UTF-8? Es muss ja irgendeine Motivation gegeben haben. Habe gedacht, man hätte vielleicht gute Gründe gehabt

Zurzeit habe ich übrigens nicht vor, meine Applikation, wo sich diese Frage stellt, mit .NET oder Java zu programmieren, oder auch nur Interop mit solchen Libraries zu betreiben. Später kommen vielleicht einige .NET/Metro-Extensions dazu, aber das ist nicht Thema. Die Frage ist sowieso eher theoretisch zu verstehen.

MFG

Derzeit tendiere ich zu std::wstring, weil .NET und Windows UTF-16 nutzen, was in der Regel gut in wchar_t passt (beim GCC auf Linux ist wchar_t aber scheinbar 32 Bit lang; Platzverschwendung ist mir aber egal). Was sollte man wählen, wenn man seine Applikation möglichst portabel halten will?

MfG

C++11 kennt zusätzlich std::u16string und std::u32string und Stringliterale für UTF-8/16/32. std::wstring würde ich nicht mehr verwenden.
In UTF-32 wird für ein Zeichen (eigentlich code point) 32 Bit verwendet. Beim Abzählen oder Splitten dürfte das wohl am einfachsten sein, verschwendet aber für "westliche" Sprachen entsprechend viel Platz.

Wenn du es portabel willst, dann nimm auf keinen Fall std::wstring. Willst du wirklich UTF-16 (will man nicht), dann nimm halt std::u16string.

/rant/ schrieb:

Natürlich hat man mit UTF-16 die gleiche "Problematik". Ein Zeichen muss nicht in 16 Bit passen. Das ist ja genau meine Frage: Warum hat man bei Java, .NET und diversen Betriebssystemen den Schritt gemacht und gesagt, wir nutzen UTF-16 und nicht UTF-8? Es muss ja irgendeine Motivation gegeben haben. Habe gedacht, man hätte vielleicht gute Gründe gehabt

Das ist historisch bedingt. Früher war Unicode 16 Bit (UCS-2). Aber das hat sich geändert und man musste UTF-16 einführen. Heute würden die sicher lieber UTF-8 nehmen.

Konstant bleibend breite Zeichencodes (UCS2/UCS4) sind natürlich schneller verarbeitbar als dynamisch breite Zeichencodes (UTF-8).
Deshalb nutzen Java, NT und OSX intern kein UTF-8.

UTF-16 ist auch nicht konstant breit. Das Java/Windows UTF-16 nutzen ist einfach historisch, weil sie früher auf UCS-2 gesetzt haben. Und selbst bei UTF-32 gibt es immer noch Combining Characters. OSX nutzt als Unix-System durchaus UTF-8.