Gibt es Updates der Lokalisierungsunterstützung in C++ 0x?

Question

Je mehr ich mit C++ - Locale-Facetten arbeite, desto mehr verstehe ich - sie sind gebrochen.

• std::time_get - nicht mit std::time_put (wie es in C strftime/strptime) symmetrisch und erlaubt kein einfaches Parsing Mal mit AM/PM Mark.
• I discovered Kürzlich kann diese einfache Zahlenformatierung unter bestimmten Gebietsschemata illegales UTF-8 erzeugen (wie ru_RU.UTF-8).
• std::ctype ist sehr vereinfachend unter der Annahme, dass nach oben/nach unten kann auf der Basis pro Zeichen erfolgen (Fall Konvertierung kann die Anzahl der Zeichen ändern und es ist abhängig von Kontext).
• std::collate - unterstützt keine Sortierungsstärke (Groß-/Kleinschreibung oder Insensitivität).
• Es gibt keine Möglichkeit, die Zeitzone anders als die globale Zeitzone in der Zeitformatierung anzugeben.

Und vieles mehr ...

• Hat jemand weiß, ob Änderungen in Standard Facetten in C++ 0x erwartet werden?
• Gibt es eine Möglichkeit, eine Bedeutung solcher Änderungen zu bringen?

Danke.

EDIT: Clarifications, falls die Verbindung nicht zugänglich ist:

std::numpunct definiert Tausendertrennzeichen als char. Also, wenn Trennzeichen in U + 2002 - andere Art von Raum kann nicht als einzelnes Zeichen in UTF-8 aber als mehrere Byte-Sequenz reproduziert werden.

In C API struct lconv definiert Tausende Trennzeichen als Zeichenfolge und leidet nicht unter diesem Problem. Wenn Sie also versuchen, Zahlen mit Trennzeichen außerhalb von ASCII mit UTF-8-Gebietsschema zu formatieren, wird ungültiges UTF-8 erstellt.

um diesen Fehler zu schreiben 1234 std reproduzieren: Ostream mit tränkt ru_RU.UTF-8 locale

EDIT2: ich, dass POSIX C Lokalisierung API arbeitet viel glatter muss zugeben:

• Es gibt Inverse von strftime - - strptime (strftime tut das gleiche wie)
• Keine Probleme mit der Formatierung von Zahlen wegen der oben genannten Punkt.

Allerdings ist es immer noch für perfecet.

EDIT3: Nach den neuesten Hinweise zu C++ 0x kann ich sehen, dass std::time_get::get - ähnlich wie strptime und gegenüber std::time_put::put.

Answer 1

std::numpunct ist eine Vorlage. Alle Spezialisierungen versuchen, das Dezimaltrennzeichen zurückzugeben.Offensichtlich sollten Sie in jedem Gebietsschema, in dem dies ein breites Zeichen ist, std::numpunct<wchar_t> verwenden, da die <char Spezialisierung das nicht kann.

Das heißt, C++ 0x ist ziemlich fertig. Wenn jedoch gute Verbesserungen fortfahren, wird das C++ - Komitee wahrscheinlich C++ 1x starten. Das ISO C++ Komitee nimmt Ihre Hilfe sehr wahrscheinlich an, wenn es von Ihrer nationalen ISO-Mitgliedsorganisation angeboten wird. Ich sehe, dass Pavel Minaev einen Fehlerbericht vorgeschlagen hat. Das ist technisch möglich, aber die Probleme, die Sie beschreiben, sind allgemeine Designbeschränkungen. In diesem Fall besteht die sicherste Vorgehensweise darin, eine Boost-Bibliothek zu entwerfen, die Boost-Überprüfung bestehen zu lassen, sie für die Aufnahme in den Standard einzureichen und an den ISO C++ - Sitzungen teilzunehmen, um dort auftretende Probleme zu behandeln.

Answer 2

Ich stimme dir zu, C++ fehlt die richtige i18n Unterstützung.

Weiß jemand, ob Änderungen in Standardfacetten in C++ 0x erwartet werden?

Es ist zu spät im Spiel, also wahrscheinlich nicht.

Gibt es eine Möglichkeit, eine Bedeutung solcher Änderungen zu bringen?

Ich bin sehr pessimistisch darüber.

Stroutrup behauptete direkt, dass er keine Probleme mit dem aktuellen Status sieht. Und ein anderer der großen C++ - Leute (Buchautor und alle) hat nicht einmal gemerkt, dass wchar_t ein Byte sein kann, wenn Sie den Standard lesen.

Und einige Threads in Boost (die die Richtung in die Zukunft zu fahren scheint) zeigen so wenig Verständnis, wie das funktioniert, das ist wirklich gruselig.

C++ 0x kaum hinzugefügt einige Unicode-Charakter-Datentypen, spät im Spiel und nach viel Mühe. Ich halte nicht zu lange den Atem an.

Ich denke, die einzige Chance, etwas besser zu sehen ist, wenn jemand wirklich gut/respektiert in den i18n und C++ Welten direkt in die nächste Version des Standards einbezogen wird. Keine Ahnung, wer das sein könnte :-(