Unicode - von wegen ...
-
"Glib::ustring" in der glibmm behauptet von sich selbst, UTF-8 zu nutzen und liefert auch nen << und >> für streams mit.
-
otze schrieb:
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
Insofern hat Qbert² ja Recht, C++ unterstützt Unicode definitiv nicht zur vollsten Zufriedenheit
-
otze schrieb:
Wenn das Betriebssystem kein Unicode kann, muss es wchar_t auch nicht können.
Das stimmt. Und der Witz daran ist, dass Windows selbst intern Unicode verwendet und da wchar_t kein Multibyte-Zeichen sein darf, müsste Microsoft - würde es sich an den Standard halten - wchar_t vier Byte groß machen und UCS-4 implementieren
Die iostream locales sind dann noch ein ganz anderes Paar schuhe.
Grundsätzlich schon. Aber wenn die Umgebung entsprechende UTF-8-taugliche Locales bereitstellt und dazu noch UCS-4 als wchar_t, dann ist das schon ziemlich Unicode-tauglich und praktisch
-
otze schrieb:
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
So ein Quatsch! Ich kann mir auch eine fertige nehmen!
-
Artchi schrieb:
otze schrieb:
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
So ein Quatsch! Ich kann mir auch eine fertige nehmen!
Theoretisch: richtig. Praktisch: kennst du eine Gute?
(Bitte jetzt nicht wieder ICU, ich meine *gut* ... im Sinn von "kein Mist")
-
Theston schrieb:
"Glib::ustring" in der glibmm behauptet von sich selbst, UTF-8 zu nutzen und liefert auch nen << und >> für streams mit.
-
hustbaer schrieb:
Artchi schrieb:
otze schrieb:
Wer unicode support will, muss sich dafür selbst eine lib bauen(und darf dann auch nicht auf wchar_t aufsetzen)
So ein Quatsch! Ich kann mir auch eine fertige nehmen!
Theoretisch: richtig. Praktisch: kennst du eine Gute?
(Bitte jetzt nicht wieder ICU, ich meine *gut* ... im Sinn von "kein Mist")Was wollt ihr eigentlich konkret? Geht es um das rein und raus schreiben von UTF-8-Strings? Ob die Strings im RAM als UTF8 oder wchar_t liegen ist doch egal.
Wenn ihr keine codecvtl-Implementierung für UTF-8 kennt, tut es mir echt leid! Es gibt von Boost eine UTF-8-codecvt, jeder der boost auf seiner Platte hat, hat diese auch im Zugriff. Von boost.serialize und boost.filesystem wird diese auch genutzt.Hier wird mal wieder gegen C++ Sturm gemacht und das völlig ohne Grund.
Wem Boost zu unseriös ist, kann auch bei Dinkumware eine umfangreiche C++-Std-Lib-Implementierung kaufen, die diverse Codecs unterstützt:
http://www.dinkumware.com/manuals/default.aspx?manual=compleat&page=index_cvt.html#Code Conversions (arbeitet problemlos mit wstring zusammen!)Selbst bauen zeugt nur davon, das man sich nicht informiert hat, was der C++-Herstellermarkt so anbietet.
-
Naja... entweder hab ich's übersehen, oder das Teil ist nicht sehr vollständig. So korrekte "line break" Punkte ermitteln, Shaping, BiDi, das gehört für mich alles zu UNICODE dazu.
-
@Artchi hier wird nicht sturm gemacht. Das C++ Commitee sagt selbst zum Thema Unicode, dass sie nicht planen, was an der unicode unterstützung zu ändern. das ist ein Fakt.
Und defacto musst du dir für private interessen eine eigene lib bauen, denn es gibt keine gute freie, die mit den bestehenden C++ mitteln zusammenarbeitet.(iostreams, basic_string etc)
Was wollt ihr eigentlich konkret? Geht es um das rein und raus schreiben von UTF-8-Strings? Ob die Strings im RAM als UTF8 oder wchar_t liegen ist doch egal.
nein, ist es nicht. denn du musst immer wissen, welche codierung dein wchar_t hat, und deshalb ist eine "einfache" plattformunabhängige Lösung mit wchar_t nicht möglich. Natürlich, wer nur für windows compiliert, dem wird das alles nicht schwer fallen, aber wer eine allgemeine Lösung will, sitzt ziemlich auf dem trockenen.
-
Artchi schrieb:
Hier wird mal wieder gegen C++ Sturm gemacht und das völlig ohne Grund.
--> http://de.wikipedia.org/wiki/Paranoia
(schleichende Entwicklung eines dauernden, unerschütterlichen Wahnsystems)
