Guter Stil oder Overhead?
-
Wie fragst du denn std::string?
-
Ja, toUpper funktioniert hier nur, wenn man Information-Hidding verletzt und annimmt, man weiß wie der String seine Daten intern hält.
-
Irgendwie verstehe ich nicht, worauf du gerade hinaus willst.
-
hmmmm schrieb:
Wie frage ich
std::vector<char>nochmal nach seinem Encoding?Gar nicht. Die Unterstuetzung fuer Utf in C++ ist nicht besonders gut. Aber deswegen kannst du trotzdem eine Klasse
UtfStringdefinieren undtoUpperdafuer spezialisieren, die das Encoding abfragt.Ja, toUpper funktioniert hier nur, wenn man Information-Hidding verletzt und annimmt, man weiß wie der String seine Daten intern hält
Wie du siehst, kann das am Typ festgemacht werden. Und warum sollte ich den verstecken?
-
ist glaub ich sinnlos weietr zu machen.
-
hmmmm schrieb:
Ja, toUpper funktioniert hier nur, wenn man Information-Hidding verletzt und annimmt, man weiß wie der String seine Daten intern hält.
ähh...nein? Iteratoren?
-
ähh...nein! Encoding weiterhin undefiniert.
Utf8String Utf16String Utf32String kommen gleich vorbei...
-
aber das Encoding kennt std::string ja selbst nicht. Ich würde ja jetzt sagen: "locale fragen" aber das geht nicht, wenn du UTF8-kodierst. std::string ist nicht für variable-breite zeichen ausgelegt. UTF-32 (mit unsigned int als char_t) würde aber gehen. Also: richtigen Stringtyp verwenden und dann locale fragen(und facets implementieren). Oder auf wchar_t hoffen und locale fragen. Unter Unixoiden funktioniert das sogar.
-
Ist es nicht offensichtlich, welches Encoding verwendet wird?
ASCII ist ein Subset von UTF-8, also kann man wohl bei jedem 8bit-string annehmen, dass er UTF-8 kodiert ist.
Bei einem 16bit-Typen gehe ich von UTF-16 aus, analog dazu von UTF-32 bei 32bit.Ein Denkfehler dabei?
-
Ja, das 8Bit eben nicht UTF-8 bedeutet. Es kann auch zum Beispiel ein beliebiger erweiterter ASCII sein wie unter einigen Systemen üblich. Es muss nicht einmal ASCII kompatibel sein.