Suche guten C++ String



  • Gibts ne String Klasse die keine Probleme mit Codierungen wie z.B. UTF 8 hat. Also ich übergebe z.B. ein char array und sag das ist UTF 8 und der verarbeitet das richtig. Und die Klasse sollte nicht irgendwie in nem Framework wie MFC oder so drin sein.



  • http://www.c-plusplus.net/forum/viewtopic-var-t-is-204654-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html
    Vorher kannst du das nur aus Frameworks / Biblioteken holen. Da gibt's dann allerdings so praktische Sachen wie Glib::ustring



  • UTF-8 kannst du problemlos in std::string speichern.



  • Und ich vertrete immer noch die Meinung, dass eine Stringklasse nichts mit Codierungen zu tun hat. Ein String speichert Codepunkte. Wie er das intern macht, ist egal. Erst wenn man den String an ein Gerät (Ausgabe, Datei, …) überträgt oder von dort aus einliest, muss man mit Codierungen arbeiten. Aber das ist nicht Aufgabe des Strings sondern des Interpreters (im Falle von C++ dann eben des Streams + Locale).

    Unicode hingegen ist natürlich eine andere Sache; wenn man also z.B. einen String in Großbuchstaben umwandeln möchte, braucht man eine Möglichkeit, ihm zu sagen, dass er sich dabei z.B. an Unicode-Regeln halten soll („ß“ wird „SS“!). Aber das geht in C++ doch prinzipiell auch über Locales.



  • .filmor schrieb:

    UTF-8 kannst du problemlos in std::string speichern.

    Dann macht string.lenght aber nicht mehr das richtige

    Konrad Rudolph schrieb:

    Und ich vertrete immer noch die Meinung, dass eine Stringklasse nichts mit Codierungen zu tun hat. Ein String speichert Codepunkte. Wie er das intern macht, ist egal. Erst wenn man den String an ein Gerät (Ausgabe, Datei, …) überträgt oder von dort aus einliest, muss man mit Codierungen arbeiten. Aber das ist nicht Aufgabe des Strings sondern des Interpreters (im Falle von C++ dann eben des Streams + Locale).

    Unicode hingegen ist natürlich eine andere Sache; wenn man also z.B. einen String in Großbuchstaben umwandeln möchte, braucht man eine Möglichkeit, ihm zu sagen, dass er sich dabei z.B. an Unicode-Regeln halten soll („ß“ wird „SS“!). Aber das geht in C++ doch prinzipiell auch über Locales.

    Wozu dann String? Dir würde dann auch ein vector<char> reichen.



  • 6uzhjn schrieb:

    .filmor schrieb:

    UTF-8 kannst du problemlos in std::string speichern.

    Dann macht string.lenght aber nicht mehr das richtige

    Aber die „Länge“ eines Unicode-Strings zu bestimmen ist alles andere als trivial, ganz unabhängig von der gewählten Kodierung. Wofür will man das überhaupt?

    6uzhjn schrieb:

    Wozu dann String? Dir würde dann auch ein vector<char> reichen.

    Tut es ja im Allgemeinen auch. Aber bei std::string dürfen (und sollen) die Bibliotheksentwickler auch noch ein bisschen rumoptimieren, zB mit Copy-on-Write-Spielereien oder Ähnlichem.



  • .filmor schrieb:

    Aber die „Länge“ eines Unicode-Strings zu bestimmen ist alles andere als trivial, ganz unabhängig von der gewählten Kodierung. Wofür will man das überhaupt?

    Irgendwie verstehe ich das nicht so ganz 😞 Ich hab schon öfters gehört, dass UTF-32 z.B. auch variable Zeichenlängen hat, aber auf Wikipedia steht glasklar: "UTF-32 zeigt seine besonderen Vorteile beim wahlfreien Zugriff auf ein bestimmtes Zeichen, da die Adresse des n-ten Zeichens durch einfachste Zeigerarithmetik ermittelt werden kann."

    Hat da zufällig jemand Lust, mich aufzuklären? edit2: Ich überflieg lieber erst nochmal den Magazin-Artikel 😃

    Wenn der UTF-32-Unicode-String in "Normalization Form C" ist, müsste nicht spätestens dann jedes Zeichen in ein Element passen? Manchmal hasse ich Unicode 😡



  • .filmor schrieb:

    6uzhjn schrieb:

    .filmor schrieb:

    UTF-8 kannst du problemlos in std::string speichern.

    Dann macht string.lenght aber nicht mehr das richtige

    Aber die „Länge“ eines Unicode-Strings zu bestimmen ist alles andere als trivial, ganz unabhängig von der gewählten Kodierung. Wofür will man das überhaupt?

    Na z.B. genau darum hätte ich gern einen String der das für mich macht.
    String(chars, encoding) fertig. String soll alles (length, toUpper...) richtig machen, wie das intern gespeichert wird ist mir egal. Locale wird selbstständig ermittelt, wenn ich nix anderes sage. Bei string.length will ich natürlich die Anzahl der Zeichen und nicht der chars, bytes oder so.



  • Dann nimm doch wstring. Warum streuben sich alle dagegen?



  • Hallo

    Wenn der UTF-32-Unicode-String

    Da ist schon der Denkfehler. UTFx und Unicode sind eben nicht dasselbe! Sondern UTFx ist eine Codierungsvorschrift für Unicode, gerade um Unicode in ASCII ausdrücken zu können. Daraus folgt : UTFx in std::string, Unicode in std::wstring. Das die Länge eines UTFx-Strings größer ist als die des Unicode-Äquivalents ist doch ganz klar und auch korrekt.

    bis bald
    akari



  • 6uzhjn schrieb:

    Na z.B. genau darum hätte ich gern einen String der das für mich macht.
    String(chars, encoding) fertig. String soll alles (length, toUpper...) richtig machen, wie das intern gespeichert wird ist mir egal. Locale wird selbstständig ermittelt, wenn ich nix anderes sage. Bei string.length will ich natürlich die Anzahl der Zeichen und nicht der chars, bytes oder so.

    Mir ist klar, was du willst, ich hab auch mal sowas geschrieben (ist aber nichtmal annähernd fertig geworden) bis ich gemerkt habe, dass ich sonen Kram eigentlich nie brauche. Mir reicht ein Encoding, length brauch ich nicht, toupper etc. sind in C++ eh keine Member der Stringklasse.

    Artchi schrieb:

    Dann nimm doch wstring. Warum streuben sich alle dagegen?

    Weil wstring doof und uneinheitlich ist. Darum. Die Diskussion hatten wir schon einige Male 😉

    akari schrieb:

    Hallo

    Wenn der UTF-32-Unicode-String

    Da ist schon der Denkfehler. UTFx und Unicode sind eben nicht dasselbe! Sondern UTFx ist eine Codierungsvorschrift für Unicode, gerade um Unicode in ASCII ausdrücken zu können. Daraus folgt : UTFx in std::string, Unicode in std::wstring. Das die Länge eines UTFx-Strings größer ist als die des Unicode-Äquivalents ist doch ganz klar und auch korrekt.

    ?!
    Wie meinen?
    std::wstring ist mitnichten ein echter Unicode-String (schon gar nicht auf allen Plattformen), insbesondere ist für ihn weiterhin length() == size() und gibt die Anzahl der Codepunkte, nicht der Glyphen wieder.
    /Immer/ wenn man Unicode speichert benutzt man ein UTF (und sei es ein selbst erdachtes).

    Badestrand schrieb:

    Wenn der UTF-32-Unicode-String in "Normalization Form C" ist, müsste nicht spätestens dann jedes Zeichen in ein Element passen?

    Ich glaube ein Glyph == ein Element funktioniert mit Unicode nie, es sei denn, du schränkst dich auf ISO-8859-1 ein (was dem ganzen irgendwie den Spaß raubt ;)).



  • Hallo

    .filmor schrieb:

    std::wstring ist mitnichten ein echter Unicode-String (schon gar nicht auf allen Plattformen), insbesondere ist für ihn weiterhin length() == size() und gibt die Anzahl der Codepunkte, nicht der Glyphen wieder.
    /Immer/ wenn man Unicode speichert benutzt man ein UTF (und sei es ein selbst erdachtes).

    Natürlich ist length und size das gleiche. So ist es ja auch definiert...
    Keines von beiden soll zurückgeben wieviel Bytes der String hat. Sondern wieviele Elemente.

    Wenn std::wstring kein "echter" Unicode-String ist dann erklär doch mal was ein echter Unicode-String ist?

    bis bald
    akari



  • Unter anderem enthält std::wstring nichtmal auf allen Plattformen Unicode. Desweiteren hat er keine mit Unicode zusammenhängenden Funktionen (zB keine Member die mir die Anzahl der Glyphen zurückgeben oder ihn in eine Normalform bringen etc.)

    Dein Denkfehler ist, dass du glaubst, UTF* sei dazu da, Unicode in ASCII auszudrücken. UTF-32 drückt Unicode in 32-Bit-Ganzzahlen aus, was ganz und gar nicht ASCII ist. Nichtmal UTF-8, auf das das noch am ehesten zuträfe ist ASCII, da es eben 8-bittig und nicht 7-bittig wie ASCII ist.
    Die UTFs sind dazu da, Unicode /überhaupt/ irgendwie zu speichern, was nunmal am Besten in Oktetten geht, da die von allen relevanten EDV-Systemen benutzt werden.


Anmelden zum Antworten