Konflikte: Definition von wchar_t Zeichenfolge in C ++ Standard und Windows-Implementierung?

Question

Von c ++ 2003 2,13

Eine breite Stringliteral hat Typen „ Array von n const Wchar_t “ und hat statische Lagerdauer, wobei n die Größe der Zeichenfolge wie nachstehend definiert

Die Größe eines breiten Stringliteral ist die Gesamtzahl der Escape-Sequenzen, Universal-Charakter-Namen und andere Zeichen, plus eine für das abschließende L‘\ 0’ .

Aus c ++ 0x 2.14.5

Eine breite Stringliteral hat Typen „ Array von n const Wchar_t “, wobei n die Größe der Zeichenfolge wie nachstehend definiert

Die Größe eines char32_t oder breiten Stringliteral ist die Gesamtzahl der Escape-Sequenzen, Universal-character-Namen und anderer Zeichen, plus eines für das Beenden U‘\ 0’ oder L‘ \ 0’ .

Die Größe eines char16_t Stringliteral ist die Gesamtzahl der Escape-Sequenzen, Universal-character-Namen und andere Zeichen, plus eins für jedes Zeichen ein Ersatzpaar benötigt, plus eins für das Beenden u ‚\ 0‘.

Die Anweisung in C ++ 2003 ist recht vage. Aber in C ++ 0x, wenn die Länge der Zeichenfolge zu zählen, die breite Stringliteral Wchar_t wird genauso wie char32_t behandelt werden, und unterscheidet sich von char16_t.

Es gibt einen Beitrag, dass die Staaten deutlich, wie Windows implementiert wchar_t in https://stackoverflow.com/questions/ 402.283? tab = Stimmen% 23tab-top

Kurz gesagt, wchar_t in Fenstern ist 16bits und codiert mit UTF-16. Die Aussage in Standard läßt offenbar etwas in Windows Konflikt zu geraten.

zum Beispiel

wchar_t kk[] = L"\U000E0005";

Dies übersteigt 16bits und für UTF-16 braucht es zwei 16-Bit-es (ein Ersatzpaar) zu kodieren.

jedoch von Standard kk ist ein Array von 2 Wchar_t (1 für den universellen-namen \ U000E005, 1 für \ 0).

Aber im internen Speicher, mußte Windows-3 16-Bit-Wchar_t speichern Objekte, 2 wchar_t für das Ersatzpaar und 1 wchar_t für die \ 0. Daher ist aus Array-Definition, kk ist ein Array von 3 wchar_t.

Es ist offensichtlich miteinander in Konflikt.

Ich denke, eine einfache Lösung für Windows ist alles zu „Verbot“, das in wchar_t ( „Verbot“ jeder Unicode außerhalb BMP) Ersatzpaar erfordert.

Gibt es etwas falsch mit meinem Verständnis?

Danke.

Answer 1

Der Standard verlangt, dass wchar_t groß genug sein, jedes Zeichen in dem unterstützten Zeichensatz zu halten. Auf dieser Grundlage, ich denke, Ihre Prämisse ist richtig -. Es ist falsch für VC ++ das einzelne Zeichen \U000E0005 mit zwei wchar_t Einheiten darstellen

Charaktere außerhalb des BMP werden selten verwendet, und Windows selbst intern verwendet UTF-16-Codierung, so dass es einfach bequem ist (auch wenn falsch) für VC ++ auf diese Weise zu verhalten. Anstatt jedoch diese Zeichen „Verbot“, ist es wahrscheinlich, dass die Größe der wchar_t wird in Zukunft zunehmen, während char16_t seinen Platz in dem Windows-API erfolgt.

Die Antwort, die Sie im Zusammenhang mit etwas irreführend ist auch:

Unter Linux ein wchar_t 4-Bytes, während auf Windows, es ist 2-Byte

Die Größe des wchar_t hängt allein von den Compiler und hat nichts mit dem Betriebssystem zu tun. Es passiert einfach, dass VC ++ verwendet 2 Bytes für wchar_t, aber noch einmal, das sehr gut in der Zukunft ändern könnte.

Answer 2

kennt Windows-nichts über wchar_t, weil wchar_t ein Programmierkonzept ist. Im Gegensatz dazu Wchar_t nur Lagerung, und es weiß nichts über den semantischen Wert der Daten, die Sie darin speichern (das heißt, es weiß nichts über Unicode oder ASCII oder was auch immer.)

Wenn ein Compiler oder SDK, dass die Ziele von Windows definiert wchar_t 16 Bits sein, so dass Compiler in Konflikt mit dem C sein kann ++ 0x-Standard. (Ich weiß nicht, ob es gibt einige get-out-Klauseln, mit denen Wchar_t 16 Bits.) Aber in jedem Fall der Compiler könnte definieren Wchar_t 32 Bit (nach der Norm entsprechen) und Runtime-Funktionen zu konvertieren bieten / von UTF-16, wenn Sie Ihre wchar_t * auf Windows-APIs übergeben müssen.