dot hat geschrieben: Ist imo wohl gar nichtmal wirklich nötig, zumal es wohl sowieso keinen Weg gibt das für UTF-8 effizient (O(1)) zu implementieren!?
Mit ner Tabelle, auf welchem Byte das xte Zeichen anfängt :) Das wär O(1), wenn auch ne ordentliche Verschwendung von Lebenszeit des Programmierers, weil es eigentlich nie gebraucht wird.
dot hat geschrieben:
Seh ich nicht so. Nur weil einige Dinge funktionieren, ist es noch lange keine gute Lösung. Eine gute Lösung zeichnet sich nicht dadurch aus, dass manche Dinge trotzdem funktionieren, sondern eben in wesentlichen Teilen dadurch, dass Dinge die semantisch keinen Sinn machen oder gar direkt und geradeaus einfach falsch sind sich gar nicht erst hinschreiben lassen...
Hm... also würde es Deine Anforderungen erfüllen, wenn man von std::string private erbt und nur die gültigen Funktionen public reimportiert? Das wäre eine Lösung. Und dazu Vorsicht: ich hatte das mal gemacht und dann festgestellt, dass diverse Automatismen wie z.b. std::hash, die für std::string spezialisiert sind, dann nicht mehr anspringen. Wenn man das weiß, geht das.
Was UTF-8 als die Lösung aller Probleme angeht bin ich auch eher skeptisch. Für Serialisierung etc. ist UTF-8 sicherlich unangefochten die beste Lösung. Aber imo haben UTF-16 und UTF-32 auch nicht zu verachtende Vorteile was das Speicherlayout angeht. Vermutlich würde ich mich im Moment aber wohl auch für UTF-8 entscheiden...
Hm... das halte ich für Geschmackssache. Für Chinesen ist UTF16 sicher speichersparender, und UTF32 ist ja in allen praktischen Belangen kein UTF mehr :-) Für mich ist aber nur UTF8 die wirklich geniale Lösung, weil sie komplett transparent mit ASCII interagiert. Und nur das ist ja mein Argument, dass man eben aufwandsarm zu einer Lösung für alle Sprachen migrieren kann und dabei portionsweise Probleme löst, wenn sie auftreten. UTF16 dagegen wäre eine einzige große HauRuck-Aktion.
