kaiserludi hat geschrieben:- es gehört zur C Standard Lib und ist damit auf allen standardkonformen Plattformen vorhanden
Wie kompatibel
wchar_t zur Standardbibliothek ist, habe ich
hier gesehen.
kaiserludi hat geschrieben:Dass wchar_t auf Windows 16Bit und UTF16 und auf Unix 32 Bit und UTF 32 ist, ist bei sauberem Softwaredesign völlig egal.
Zuerst einmal ist die Größe von
wchar_t nicht vom Betriebssystem, sondern vom Compiler abhängig. Und genauso die Kodierung. Ich habe in meinen alten Quelltexten noch eine Notiz, dass Visual C++ UCS-2 verwendet und damit inkompatibel zur WinAPI ist, die UTF-16 erwartet (aber zumindest bei Visual C++ 2010 ist das nicht mehr der Fall, alles UTF-16 dort).
kaiserludi hat geschrieben:UTF8 ist zwar in der Theorie ganz toll, aber da es nicht im Standard ist, bietet leider nicht jede Plattform auch nur ansatzweise alle überlebenswichtigen Funktionen dafür an, weswegen ich in der API wchar_t für sinnvoller als multibytestrings halte
Wie du selber gesagt hast:
wchar_t ist UTF-16, und das
ist multi-byte. Die Standardbibliothek bietet nicht
eine Zeile mehr Unicode-Unterstützung für
wchar_t als für
char. Steck ein UTF-16-Zeichen jenseits der 0xFFFF in einen
::std::wstring, frag
length() ab und begreif, dass da nicht die Anzahl der Buchstaben (Code Points), sondern die Anzahl der Speichereinheiten (Code Units) zurückkommt (ist ja auch im Standard als gleichbedeutend mit
size() definiert).
Noch dazu
darf C++-Quelltext überhaupt keine Sonderzeichen enthalten. C++-Quelltext
müsste ASCII-only sein. Das bedeutet: In dem Augenblick, wo du im Quelltext einen Umlaut in eine Zeichenkette schreibst – egal, ob normal oder mit
L davor –, ist die Zeichenkette nicht mehr portabel.
Für solche Fälle hat der Standard Escape-Sequenzen vorgesehen; wenn du UTF-16 benutzen wolltest, würdest du den Umlaut
ä also im Quelltext gemäß seiner Unicode-Position bei U+00E4 mit
L'\x00E4' ausschreiben.
Das funktioniert bei den unteren 65536 Werten noch ganz gut. Jetzt willst du aber ein Zeichen an höherer Position kodieren. Geht nicht, weil Escape-Sequenzen nur vier Hex-Ziffern akzeptieren. Oh. Also jagst du das erstmal durch einen Online-Konvertierer, der dir (rein exemplarisch) die UTF-16-Folge
0xD0FE, 0xDE15 ausspuckt. Die schreibst du rein und die läuft. Unter Visual C++ jedenfalls. GCC produziert aber nur Müll, weil es
wchar_t in 32 Bits kodiert und UTF-32 erwartet. Und das ist dann der Punkt, an dem man begreift, dass
wchar_t eine an allen Ecken und Enden missratene Fehlgeburt ist, die provisorisch irgendwo an den Standard gekleistert wurde – und was von vorne bis hinten als
implementation-defined „standardisiert“ ist, ist für breite Anwendung eben einen feuchten Kehricht wert.
Zusammengefasst: Die Standardbibliothek bietet keine Unicode-Unterstützung, C++ bietet (noch) keine Unicode-Unterstützung und
wchar_t ist, auf den Punkt gebracht, nichts anderes als
ein Container irgendeiner Größe für wenn man mal breite Buchstaben irgendwelcher Art braucht. Wenn du also UTF-16 oder UTF-32 benutzen möchtest, musst du dir so oder so eigene Funktionen zusammenschustern. Wenn du sie darüber hinaus auch noch
mit wchar_t benutzen willst, musst du dir sogar
doppelt so viel zusammenschustern, weil du auf der einen Plattform mit UTF-16 und auf der anderen mit UTF-32 arbeiten musst.
Darum ist die einfachste und beste Lösung: Scheiß auf
wchar_t und benutz
uint16_t, um deine Buchstaben
überall in UTF-16 zu speichern. Und wenn du nicht damit rechnen musst, dass ein Großteil der Strings in deinem Programm mal auf Chinesisch sein wird oder sie dauernd durch die WinAPI müssen, bleib direkt bei UTF-8.
Falls ich da was verpeilt haben sollte, bitte korrigieren. Ist schon ein wenig her, dass ich mich mit
wchar_t rumplagen musste.
(Das waren jetzt viele Betonungen … aber Rants machen mich immer so emotional, schon per Definition <3)
————
dawit hat geschrieben:da es ist leider scheinbar gar nicht möglich, eine kleine/kompakte UTF-8 lib zu schreiben, weil allein die ganzen lookup tables schon knapp 10Mb beanspruchen.
Welche LUTs? Wofür?
