ÄÖÜäöüß .. ist die Welt noch nicht kompliziert genug ?

[CodingCat]

Das Interface kann mMn schon beibehalten werden, muss aber halt noch erweitert werden. Schau dir mal Glib::ustring an. Das Interface ist weitestgehend identisch zum std::string und wurde um bestimmte Methoden erweitert. Die Implementierung/Funktionalität muss natürlich geändert werden und genau dafür wären halt virtuelle Methoden und public Vererbung wichtig.

Nur so am Rande, Vererbung ist hierfür ganz sicher keine gute Wahl. Spätestens wenn du einen angepassten String, übergeben mit dem Typ der Oberklasse (i.d.F. also std::string), kopierst (und Strings werden zwangsläufig ständig kopiert), hast du wieder einen Byte-Puffer, und alle Mühe war umsonst. Damit das halbwegs sinnvoll wird, bräuchtest du ein echtes String-Interface. Das geht jedoch voll an der Idee der STL vorbei, Polymorphie ohne Overhead zur Compilezeit zu realisieren, indem das implizite Interface (= Methoden und Funktionen mit Namen und Signatur, nicht virtual) bei wechselndem Typ gleichbleibt. Deshalb ist es schon ganz richtig, dass STL-Klassen nicht zur Ererbung gedacht sind, sondern neue Klassen einfach ohne Vererbung das implizite Interface übernehmen.

Eine bessere Lösung für eine reine Erweiterung wäre, char_traits um entsprechende Trait-Methoden oder -Eigenschaften (z.B. n-tes Zeichen oder Indexoperator ja/nein?) zu ergänzen, auch das wäre jedoch nur bedingt sinnvoll, weil einige Methoden wohl zwangsläufig von O(1) zu O(n) wechseln würden.

Nachtrag: Tatsächlich ist Glib::ustring alles andere als konform, so kann es beispielsweise zwangsläufig keine veränderbaren Referenzen auf einzelne Zeichen zurückgeben. Das std::string-Interface ist damit für derlei Zwecke wohl einfach gänzlich ungeeignet.

[BeRsErKeR]

Das Interface kann mMn schon beibehalten werden, muss aber halt noch erweitert werden. Schau dir mal Glib::ustring an. Das Interface ist weitestgehend identisch zum std::string und wurde um bestimmte Methoden erweitert. Die Implementierung/Funktionalität muss natürlich geändert werden und genau dafür wären halt virtuelle Methoden und public Vererbung wichtig.

Nur so am Rande, Vererbung ist hierfür ganz sicher keine gute Wahl. Spätestens wenn du einen angepassten String, übergeben mit dem Typ der Oberklasse (i.d.F. also std::string), kopierst (und Strings werden zwangsläufig ständig kopiert), hast du wieder einen Byte-Puffer, und alle Mühe war umsonst. Damit das halbwegs sinnvoll wird, bräuchtest du ein echtes String-Interface. Das geht jedoch voll an der Idee der STL vorbei, Polymorphie ohne Overhead zur Compilezeit zu realisieren, indem das implizite Interface (= Methoden und Funktionen mit Namen und Signatur, nicht virtual) bei wechselndem Typ gleichbleibt. Deshalb ist es schon ganz richtig, dass STL-Klassen nicht zur Ererbung gedacht sind, sondern neue Klassen einfach ohne Vererbung das implizite Interface übernehmen.

Ich wollte nicht anzweifeln, dass die Implementierung der STL ihre Gründe hat. Mit der Vererbung magst du Recht haben. Die Jungs von glib scheinen die Philosophie von STL ja dann in gewisser Weise auch berücksichtigt zu haben. Ob nun freiwillig oder nicht.

Nachtrag: Tatsächlich ist Glib::ustring alles andere als konform, so kann es beispielsweise zwangsläufig keine veränderbaren Referenzen auf einzelne Zeichen zurückgeben. Das std::string-Interface ist damit für derlei Zwecke wohl einfach gänzlich ungeeignet.

Dann sind wir uns ja einig. ;)

[dot]

Ich würde einem UTF-8 string kein Interface zum wahlfreien Zugriff auf einzelne Zeichen geben, da das wie gesagt für UTF-8 nicht effizient implementierbar ist.
Ein UTF-8 string hätte bei mir wohl einfach nur Forward/BackwardIteratoren, das reicht in der Regel. Und allein darum schon, kann das Interface von std::string imo nicht einfach übernommen werden.

[BeRsErKeR]

Ich würde einem UTF-8 string kein Interface zum wahlfreien Zugriff auf einzelne Zeichen geben, da das wie gesagt für UTF-8 nicht effizient implementierbar ist.
Ein UTF-8 string hätte bei mir wohl einfach nur Forward/BackwardIteratoren, das reicht in der Regel. Und allein darum schon, kann das Interface von std::string imo nicht einfach übernommen werden.

Falls du aber mal ein Zeichen an Position n auslesen musst und dich dann eh über Iteratoren hinhangeln musst, kann die Implementierung des Index-Operators mindestens genauso schnell sein indem sie eben genau dieses Vorgehen anwendet. Oder wenn möglich noch effizienter.

Ein myString[5] = 'x'; ist halt wesentlich lesbarer und intuitiver als ein Durchiterieren. Der Code dahinter kann ja identisch sein. Wenn ich mit Strings arbeite, dann möchte ich das halt auch relativ komfortabel können. Ob die Implementierung nun effizient ist, ist zwar auch wichtig, aber da es (wie du sagst) eh nicht wirklich effizient geht, möchte ich doch wenigstens eine relativ logische und kompakte Syntax nutzen können.

Allerdings bin ich nun auch nicht unbedingt dafür, solch eine Klasse in die STL zu integrieren, schon allein weil es dort irgendwie nicht reinpasst. Für mich ist std::string auch nicht mehr als eine etwas sicherere und dynamischere Alternative zu char-Arrays bzw. eine etwas angepasstere Variante vom std::vector<char> mit ein wenig Zusatzfunktionalität und keine wirkliche String-Klasse. Es ist einfach ein Container für Zeichen mit gleicher Bytegröße und daher schon per se nicht kompatibel zu UTF-8.

[dot]

Falls du aber mal ein Zeichen an Position n auslesen musst und dich dann eh über Iteratoren hinhangeln musst, kann die Implementierung des Index-Operators mindestens genauso schnell sein indem sie eben genau dieses Vorgehen anwendet. Oder wenn möglich noch effizienter.

Da würde ich einfach std::advance() benutzen.

Ein myString[5] = 'x'; ist mit UTF-8 auch schon wieder so eine Sache. Du kannst nicht einfach eine Referenz auf ein Element in dem String returnen wie Cat schon aufgezeigt hat. Du müsstest z.B. ein Proxy-Objekt returnen das im Bedarfsfall den string modifiziert. Und dann werden durch sowas simples wie so einen Elementzugriff plötzlich iteratoren ungültig...
Genau aus solchen Gründen ist es imo besser, eben keinen operator [] anzubieten, der bringt einen nur auf dumme Gedanken ;)

Wieso findest du denn dass sowas nicht in die Standardlibrary passen würde? Man bräuchte eben ein etwas anderes Interface für diese abstraktere Sicht auf einen String. Vermutlich würde wohl etwas in der Richtung wie es z.B. in C# gemacht wird rauskommen, wo Strings non mutable sind.
Ein entsprechender Container der mit variable length encoded Sequences umgehen kann, zusammen mit Support für verschiedene Encodings und geeigneten Iteratoren (oder Ranges) wäre vermutlich extrem mächtig. Ich denk da grad an automatische Konvertierung zwischen verschiedenen Encodings per std::copy oder operator =, alles statisch geinlined...

[HeinzK]

Die Cooperate World frustriert mich zusehends ...

Kann ich nur nochmals wiederholen: Die Cooperate World frustriert mich zusehends! Übrigens Interessante Diskussion .. was man alles so programmieren könnte und sollte .. aber eigentlich wollte ich in meiner (begrenzten) Freizeit ein Spiel programmieren. Könnte man das Problem nicht mit UNICODE auch für Linux lösen? :idea:

[BeRsErKeR]

Ein myString[5] = 'x'; ist mit UTF-8 auch schon wieder so eine Sache. Du kannst nicht einfach eine Referenz auf ein Element in dem String returnen wie Cat schon aufgezeigt hat. Du müsstest z.B. ein Proxy-Objekt returnen das im Bedarfsfall den string modifiziert. Und dann werden durch sowas simples wie so einen Elementzugriff plötzlich iteratoren ungültig...
Genau aus solchen Gründen ist es imo besser, eben keinen operator [] anzubieten, der bringt einen nur auf dumme Gedanken ;)

Nunja es wird nicht einfach per Referenz gehen, das ist richtig. Aber der Operator kann ja beliebig implementiert werden. Man denke nur mal an std::operator[], der ja auch nicht nur einfach eine Referenz auf einen Eintrag liefert. Wie genau das nun implementiert werden könnte möchte ich hier auch gar nicht vorhersagen. Eine UTF-8-Stringklasse kann ja theoretisch auch Objekte vom Typ UTF-8-Char oder ähnliches verwalten und diese Klasse kann dann halt mit einer Zuweisung wie = 'x' umgehen. Was nun am effizientesten wäre können Leute entscheiden, die da mehr Erfahrung haben.

Wieso findest du denn dass sowas nicht in die Standardlibrary passen würde? Man bräuchte eben ein etwas anderes Interface für diese abstraktere Sicht auf einen String. Vermutlich würde wohl etwas in der Richtung wie es z.B. in C# gemacht wird rauskommen, wo Strings non mutable sind.
Ein entsprechender Container der mit variable length encoded Sequences umgehen kann, zusammen mit Support für verschiedene Encodings und geeigneten Iteratoren (oder Ranges) wäre vermutlich extrem mächtig. Ich denk da grad an automatische Konvertierung zwischen verschiedenen Encodings per std::copy oder operator =, alles statisch geinlined...

Ich weiß nicht so recht, aber die STL ist für mich eine sehr grundlegende Hilfsbibliothek, die wenig spezialisierte Klassen und Funktionen enthält, aber dafür die grundlegenden Dinge sehr schnell erledigt. Ein UTF-8-String ist für mich schon etwas Spezielleres, was sich halt auch an einem gewissen Standard orientiert, der kein Teil von C++ ist. Ein String ist für mich genau wie ein Array oder ein Integer halt Bestandteil einer Programmiersprache; ein UTF-8-String ist schon ein Spezialfall und würde für mich z.B. in die Kategorie einer Grafikklasse passen, die mMn auch nicht in die STL passen würde. Ich weiß nicht ob ich das nun verständlich ausdrücken konnte. Kurz gesagt: Alles was zu speziell wird hat in meinen Augen in der STL nichts verloren, sondern gehört eher in weiterführende Bibliotheken. Oder anders: Ein UTF-8-String ist für mich kein grundlegender Teil einer Programmiersprache und da würde ich die STL schon irgendwie dazu zählen.

Deine Idee mit dem Container, der mit Elementen variabler Länge umgehen kann, würde mMn aber wieder in die STL passen. Schon allein weil er für verschiedenste Anwendungen wichtig sein könnte und ein relativ grundlegender Container ist. Wenn es dann bei einem typedef std::variable_length_container<IrgendeinTyp> UTF-8-String bleibt, dann kann das von mir aus auch in die STL. Aber das wird sehr wahrscheinlich nicht klappen, da man solch einen Container mit der STL-Philosophie eher ziemlich allgemein halten würde.

[BeRsErKeR]

Die Cooperate World frustriert mich zusehends ...

Kann ich nur nochmals wiederholen: Die Cooperate World frustriert mich zusehends! Übrigens Interessante Diskussion .. was man alles so programmieren könnte und sollte .. aber eigentlich wollte ich in meiner (begrenzten) Freizeit ein Spiel programmieren. Könnte man das Problem nicht mit UNICODE auch für Linux lösen? :idea:

Redest du von deinem Problem mit Umlauten? Also in UNICODE (ich rede hier mal von UTF-16) kannst du eigentlich ziemlich viel unterbringen und sofern du dein Spiel nicht auf dem asiatischen Markt vertreiben willst wirst du damit auch langfristig auskommen. Der Vorteil ist halt, dass du durch die konstante Länge eines Zeichens es etwas leichter hast (z.B. einfach einen std::wstring nutzen kannst). Ob das nun in deinem Fall eine gute Lösung ist kommt auf deine Ziele und Pläne für die Zukunft an. ;)

[Schrompf]

Die Cooperate World frustriert mich zusehends ...

Kann ich nur nochmals wiederholen: Die Cooperate World frustriert mich zusehends! Übrigens Interessante Diskussion .. was man alles so programmieren könnte und sollte .. aber eigentlich wollte ich in meiner (begrenzten) Freizeit ein Spiel programmieren. Könnte man das Problem nicht mit UNICODE auch für Linux lösen? :idea:

Die Frage verstehe ich nicht. UTF8 *ist* die Lösung, bei Linux, bei Windows, auf dem C64 oder bei OSX. Speziell bei Linux erwarten (nach meinem Wissen, bitte um Korrektur) die meisten Betriebssystem-Bestandteile ihre Texte als UTF8. Windows ist da problematischer, weil es sich für UTF16 entschieden hat.