ZFX + Developia

Ok, Ich habe das Thema UNICODE gelesen. Mein Problem ist ähnlich: Der Code wird unter Windows/VisualStudio2010 einwandfrei kompiliert und ausgeführt.
Unter Linux/Ubuntu/gcc s.o..
Hinweis1: Zuerst habe ich statt 'std::wstring' ganz normal 'std::string' verwendet. Dieser Code wurde dann unter Windows und Ubuntu auch ohne Fehler kompiliert und ausgeführt. Aber in Ubuntu waren alle Umlaute nur als Rechtecke sichtbar.
Hinweis2: Ich teste gerade SFML 2.0.
Hinweis3: Im Quelltext von Ubuntu/gcc werde die Umlaute angezeigt.
? Wo geht's hier zum Bahnhof ?

Riecht für mich nach einem Problem mit den Compiler-Optionen. Überprüfe mal, oder dein Quelltext tatsächlich in UTF-8 vorliegt. Wenn das nichts hilft: Probier' mal ein wenig mit -fexec-charset=charset, -fwide-exec-charset=charset, -ftarget-charset=charset und -finput-charset=charset rum.

a) Ich bin noch 'frisch' auf Ubuntu/gcc. Wo kann ich die UTF-X-Einstellung für meinen Quelltext finden?
Hinweis: Ich nutze (oder will nutzen) den gleichen Quellcode für VS und gcc. D.h. mal ändere ich hier mal dort.
b)

-fexec-charset=charset, ..-

In welcher Umgebung setze ich diese Werte?

OK, a) habe ich gerade gefunden .. General Settings/Other Settings .. und da steht UTF-8.

Nun habe ich für mich eine Lösung gefunden .. siehe http://en.sfml-dev.org/forums/index.php ... 2#msg52842

Hallo,

ich würde das jetzt nicht unbedingt als Lösung eines Problems betrachten. So eine große Kaskade von ``if``s ist eigentlich nie sinnvoll, zumal du für jeden Spezialfall deine Funktion erweitern musst. Wie von einigen bereits vorher geschrieben, stimmt wahrscheinlich das Encoding deiner Datei nicht. Da kannst du dem Comiler noch so oft sagen das es UTF-8 sein soll, aber wenn es das nicht ist, dann kommt natürlich nur Murks raus.

Ich kann dir nur empfehlen, dich mit dem Thema Unicode und Encodings etwas genauer zu beschäftigen. "Nur mal kurz drüberfliegen" reicht bei dem Thema nicht aus. Hier kann man so viele Dinge falsch machen (Codierung der Datei, Codierung des Terminals, Codierung der GUI und Codierungsoptionen des Compilers), dass du ansonsten immer wieder darüber stolpern wirst, wenn du es nicht gleich richtig machst.

Bis dann,
Sebastian

Ich arbeite auf Win7/64Bit/VS2010 und VMWare8.0.3/Ubuntu10.03/gcc.
Die Quelltexte werden meist mit VS2010 erstellt. Die Bearbeitung erfolgt dann abwechselnd in VS2010 und gcc.
Liegt darin das Problem?

Der erste Schritt besteht darin zu prüfen, welche Codierung deine Dateien denn nun tatsächlich haben. Den Hinweis hatte eXile ja ganz am Anfang schon gegeben. Der einfachste Weg wäre vielleicht unter Visual Studio die Datei zu laden (dort scheint es ja zu funktionieren) und einmal explizit als UTF-8 zu speichern. Keine Ahnung, was für ein Format VS standardmäßig verwendet. Mit einem diff auf der alten und der neuen Datei solltest du dann auch herausbekommen, ob sich etwas geändert hat.

Mal dumm gefragt. Ist UTF-8 denn kompatibel zu UTF-16 in den ersten beiden Bytes? Ich denke eigentlich nicht. Daher bringt es doch auch wenig wenn es eine UTF-8 Datei ist und man es dann in UTF-16 (std::wstring) umwandelt. Wäre hier nicht eher ein UTF-16-Format anzuraten? Ich hab auf dem Gebiet auch nur Halbwissen. Ansonsten musste du halt mit den Charactercodes + Escapesequenz arbeiten. Ich weiß ja nicht ob dein Spiel ausschließlich deutsch wird. Falls nicht bieten sich eh Sprachen-Dateien an und dann hast du das Problem ja nicht direkt da du die Texte in beliebigem Format einliest und dann eh manuell in dein Wunschformat konvertieren musst.

Ich denke, der Kompiler wird schon ohne Probleme wie ein Weltmeister zwischen den unterschiedlichen Formaten in Quelldatei und Ziel konvertieren können. Speichere die Dateien in Visual Studio mal tatsächlich als UTF-8 ab (File → Advanced Save Options…), und teste die Dateien dann mit dem GCC.

Danke für eure Tipps. Ich habe nun die Ursache gefunden.
Unbemerkt habe ich mit einem englischen Ubuntu deutsch gesprochen.
(Ist ja auch kein Wunder bei diesen ewigen deutsch/englischen hin und her :roll:)
Also habe ich die Sprache auf Deutsch geändert .. und oh Wunder .. jetzt ist alles in Butter.
(Natürlich waren nach der Umstellung einige Dateien etwas verwirrt (es zogen seltsame Zeichen auf) .. aber es
ließ sich alles in Ordnung bringen.
Ich schreibe nun unter Windows/VS2010 ä und ö .. sehe unter Ubuntu/Code::Blocks ä und ö ..
die fertigen Programme zeigen in ihren Fenstern jeweils ä und ö .. ist das nicht ß (ohne 's') :lol: .

Das Umstellen der Betriebssystemsprache ist auch keine richtige Lösung. Damit triffst du nur zufällig die richtige Codierung der Texte und daher siehst du das Problem nicht mehr. Du willst ja gerade auf ein vernünftiges Encoding umsteigen, damit nicht mehr die Sprachen gewechselt werden müssen. Sonst kannst du das arbeiten mit wstrings auch gleich ganz sein lassen, wenn alle die selbe Codierung einstellen müssen wie du. Ich würde ausrasten, wenn ich bei jedem deutschen Text mein System umstellen würde.

Ich habe das Gefühl, dass du dich um eine vernünftige Lösung drücken möchtest ;-) Das Problem kannst du nur systematisch angehen indem du dich genau einliest und mit ein paar Test prüfst, ob du die Theorie dahinter richtig verstanden hast. Als Faustregel gilt: wenn du an einer anderen Stelle als ein deinem Programm dieses Problem zu lösen versuchst, dann machst du etwas falsch.

Eigentlich bin ich nun auf einer einheitlichen Programm-Spur. Ich benutze nur noch std::string (den std:wstring brauche ich nicht mehr).
Ich versuche mal ein Linux-Release .. dass dann auf unterschiedlichen Rechnern und Systemen getestet werden kann. Melde mich wieder.

Es gibt ein kleines Programm namens UTFCast, mit dem ich damals meine kompletten Sourcen nach UTF8 ohne Header konvertiert habe. Leider ist die kostenlose Version etwas beschränkt, und das Trottelprogramm erkennt UTF8 ohne Header nicht, sondern konvertiert das NOCHMAL nach UTF8.

Es gibt aktuell noch viele Sauereien, wenn man konsequenz sauberes Encoding verwenden will. UTF8 ohne Header halte ich für die einzig zukunftssichere und tragbare Lösung über alle Plattformen hinweg. Alle Compiler verstehen das, das ist kein Problem. Das Problem ist eher der Weg dahin. Über Linux kann ich nichts sagen, aber Visual Studio muss bei jeder neuen Datei manuell dazu gewzungen werden, wieder UTF8 zu schreiben. Und die zig Fragen im Internet an den Microsoft-Support werden jedesmal mit einem Verweis auf die Optionen geschlossen, wo es eine Einstellung gibt, Dateien als UTF8 zu speichern, nur wenn darin Zeichen außerhalb des Standard-Encodings vorkommen. Leider ist das nicht genug. Man vermisst dringend die Einstellung "Tritt den Projektmanager, der vom armen Support die ganze Zeit verleugnen lässt, dass es überhaupt einen Mangel gibt, und lass das Default Encoding global einstellen".

Die Cooperate World frustriert mich zusehends. Ich fürchte, wir kommen hier schlicht an die Grenzen der Komplexität. Irgendwann kollabiert jedes System an seiner eigenen Größe, und menschliche Hierarchien in großen Firmen sind da keine Ausnahme.

HeinzK hat geschrieben:Eigentlich bin ich nun auf einer einheitlichen Programm-Spur. Ich benutze nur noch std::string (den std:wstring brauche ich nicht mehr).
Ich versuche mal ein Linux-Release .. dass dann auf unterschiedlichen Rechnern und Systemen getestet werden kann. Melde mich wieder.

Du solltest vielleicht dran denken, dass du später noch weitere Sprachen anbieten möchtest. Und da wirst du mit std::string sehr schnell an Grenzen stoßen. Wobei Englisch und Deutsch wahrscheinlich auch ausreichen. Wie gesagt bin ich bei lokalisierbaren oder übersetzbaren Texten immer dafür das ganze in Sprachdateien auszulagern. Das macht das Visual Studio mit lokalisierbaren Resourcen auch so. Das hat z.B. auch den Vorteil, dass ggf. Übersetzer später nicht irgendwas im Quellcode oder in den Forms direkt übersetzen müssen, sondern nur die zu übersetzenden Texte vor sich haben. Aber das kommt halt immer drauf an was du für Pläne hast und wie umfangreich das Projekt ist.

std::string ist UTF8-tauglich und kann damit stressfrei alle Sprachen dieser Welt darstellen, und auch die der Alien, die Elvis vor uns geheim hält. std::string *ist* die Endlösung der String-Frage. Nur die darauf operierenden Funktionen sollten mit UTF8 klarkommen.

huch? Schon nichtmal string.length() funktioniert mit UTF-8...

dot hat geschrieben:huch? Schon nichtmal string.length() funktioniert mit UTF-8...

Es funktioniert sehr wohl, es gibt die die Anzahl Bytes im String zurück. Sonst noch Beispiele?

Wie gesagt: man muss einige der Algorithmen, die auf Strings arbeiten, umschreiben. Vor allem, wenn man tatsächlich zeichenweise manipulieren will. Eine gute Bibliothek in der Hinterhand kann da eine Menge reißen. Aber es ist kein gigantisches Alles-Oder-Nichts-Bauprojekt, man kann einfach portionsweise die Ecken anpassen, die es betrifft, und alles andere läuft erstmal wie vorher weiter. Das bekommst Du mit keiner anderen Unicode-Zeichenkodierung.

Wenn du std::string einfach nur als Byte-Buffer betrachtest, dann geht das natürlich, dann ist aber deine Betrachtungsweise von std::string falsch. Wenn du einen Byte-Buffer willst, dann nimm sowas wie std::vector<char>, dann bist du wenigstens semantisch einigermaßen in der richtigen Richtung unterwegs. Denn std::string ist eben nicht einfach nur ein Byte-Buffer. Wie siehts aus mit RandomAccess Iteratoren bzw. wahlfreiem Elementzugriff in O(1). Das kannst du mit UTF-8 knicken. std::string ist auf semantischer Ebene einfach völlig unbrauchbar für UTF-8...

Ansichtssache. [] liefert Dir nicht das xte Zeichen, das stimmt. alle find()-Varianten gehen aber genauso wie vorher, String-Verkettung, boost::format() usw. ebenso. Ich würde nicht die Klasse ersetzen, nur weil ein paar Methoden davon nicht mehr funktionieren. Du kannst Dir aber natürlich eine eigene Klasse schreiben, wenn Du O(1)-Zugriffe auf die Zeichen brauchst. Jeder, wie er mag.

Nach dem, was ich hier bisher gebraucht habe, ist Einzel-Zeichen-Bearbeitung verdammt selten. Den Font Layouter musst Du neu schreiben. Die Editier-Funktionen in der TextEingabe-GuiKomponente auch. Alles abseits davon geht einfach, ohne Änderung. Daher steht meine Aussage auch weiterhin: std::string ist Dein Freund, UTF8 die Lösung der Internationalisierungs-Probleme.

Ich nutze ebenfalls std::string mit UTF-8, tut alles was ich brauche und macht keine Probleme. Die Stringmanipulatoren der STL sind eh ein Witz, da ist es völlig egal, über wieviele Characters sich schlussendlich ein Zeichen erstreckt. Klar ist das keine Lösung für Programme, die beispielsweise Strings streng sprachlich korrekt lexikographisch sortieren müssen (i.d.F. helfen sogar noch eigene char_traits), aber für korrekte Lokalisierung taugt in der STL doch momentan eh keine einzige Klasse. Mit typedef string<utf8_t> utf8_string; lässt sich notfalls jederzeit auf Alternativen umsteigen, ich bin aber noch nie an einen Punkt gekommen, an dem ich Strings nicht einfach als Byte-Puffer interpretieren konnte (Ironische Randnotiz: Selbst der neue C++-Standard speichert in Beispielen UTF-8-Bytes in std::string :P).

Ich sehe den std::string einfach als Byte-Puffer mit Small String Optimization und terminierender Null, und zu viel mehr taugt er meiner Meinung nach auch kaum.

Schrompf hat geschrieben:Nach dem, was ich hier bisher gebraucht habe, ist Einzel-Zeichen-Bearbeitung verdammt selten.

Das stimmt, ich würde mir überhaupt überlegen, ob ich in einer UTF-8 Stringklasse sowas eigentlich brauche. 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!?

Schrompf hat geschrieben:Daher steht meine Aussage auch weiterhin: std::string ist Dein Freund, UTF8 die Lösung der Internationalisierungs-Probleme.

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. Und std::string ist für UTF-8 imo rein prinzipiell ungeeignet, auch wenn es unter gewissen Bedingungen und ständiger Vorsicht funktionieren kann...

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...

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.

std::string einfach nur als Container für Rohdaten zu halten finde ich auch etwas ungeschickt, obwohl es für die meisten Belange wahrscheinlich ausreicht. Ohne eine einheitliche Codierung und einheitliche Methoden auf der Codierung hinkt man meiner Meinung nach der Zeit ein wenig hinterher. In vielen Anwendungen ist eine Unterstützung von mehreren Sprachen einfach notwendig.

Bei Python ist man beispielsweise seit Version 3 zu einer Trennung von Bytes und Strings (im Sinne von Text) übergegangen. Text wird als Unicode-Typ repräsentiert und bietet entsprechende Methoden zur Manipulation. Möchte man nun Daten, meinetwegen ein UTF-8-codierte Datei, als Text einlesen, so wird diese als Menge von Bytes angelesen und muss explizit in Unicode (mit Angabe des vorliegenden Encodings) umgewandelt werden. Umgekehrt gilt natürlich auch, dass man ein Unicode-Objekt wieder explizit in ein Encoding umwandeln muss, wenn man es speichern möchte. Das ganze hat natürlich noch den Vorteil, dass man quasi beliebig von einem Encoding zu einem anderen kommen kann. Ich nehme mal an, dass das gleiche Konzept für andere Sprachen in der Form ähnlich angewendet wird.

Schrompf hat geschrieben:

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.

std::string wurde nicht so geschrieben, als dass man von ihr erben sollte oder vernünftig könnte. Nicht umsonst wurde Glib::ustring komplett neu implementiert und nur das Interface gleich gestaltet. std::string bietet keine virtuellen Methoden an, daher ist es recht sinnfrei davon zu erben. std::string ist ungeeignet für UTF-8 Strings. Ob man die rohen Bytedaten darin speichern kann hat damit nichts zu tun. Dafür kann ich auch nen std::vector<char> nehmen oder einen beliebigen anderen Container. Wenn ich ein length() auf einen String aufrufe, dann möchte ich die Stringlänge erhalten und nicht die Anzahl der Bytes. Es ist also eher verwirrend als nützlich einen UTF-8-String in einen std::string zu packen. Also bei mir sträuben sich bei sowas die Nackenhaare.

Jeder, wie er mag. Ich halte es für Verschwendung von Lebenszeit, sich eine eigene String-Klasse zu schreiben, nur damit die in einigen Details von std::string abweicht und dafür mit keiner anderen Komponente mehr zusammenspielt. Ich habe mir stattdessen ein Rudel statischer Helferfunktionen für den Umgang mit UTF8-Zeichen und Strings geschrieben, die mit Iteratoren arbeiten. War eine Stunde Arbeit, plus zwei weitere Stunden für Font Rendering und Layout, und jetzt spricht Splatter auch Russisch, wenn's sein muss. Oder auch arabisch oder chinesisch, aber da kommen wir vom Font Layout her schon wieder in ganze andere Themenbereiche.

Ich verstehe, dass Du eine globalere Lösung als konsequenter empfindest, aber ich persönlich halte das für Luxus. Und da das Thema ursprünglich von HeinzK stammt, der auf mich eher den Eindruck gemacht hat, dass er zeitsparsame Lösungen sucht, würde ich ihm halt das empfehlen.

Niemand sagt dass du es selber schreiben musst, fertige Lösungen sind doch sicherlich zu Hauf verfügbar.
Zusammenspiel mit Komponenten die std::string erwarten ist aufgrund der semantischen Unterschiede sowieso nicht drin, eben weil std::string nicht auf UTF-8 ausgelegt ist... ;)

Abseits davon: Mit was machst du eigentlich das Font-Layout?

Schrompf hat geschrieben:

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.

Und was die Effizienz angeht ist man dann mit UTF-16 oder UTF-32 wohl wesentlich besser dran ;)

Schrompf hat geschrieben:Für mich ist aber nur UTF8 die wirklich geniale Lösung, weil sie komplett transparent mit ASCII interagiert.

Ja das stimmt, das ist wirklich ein sehr großer Vorteil von UTF-8.

BeRsErKeR hat geschrieben:std::string wurde nicht so geschrieben, als dass man von ihr erben sollte oder vernünftig könnte.

private erben sollte problemlos funktionieren. Würd ich in dem Fall aber wohl nicht machen wollen.

dot hat geschrieben:

BeRsErKeR hat geschrieben:std::string wurde nicht so geschrieben, als dass man von ihr erben sollte oder vernünftig könnte.

private erben sollte problemlos funktionieren. Würd ich in dem Fall aber wohl nicht machen wollen.

Funktionieren schon, aber in diesem Fall würde ich ja eigentlich deshalb erben wollen um bestimmte Interfaces nach außen beizubehalten und durch Überladen die Funktionalität an UTF-8 anzupassen. Z.B. halt dass length() auch die Stringlänge in Zeichen zurückgibt. Die Leute, die Glib::ustring geschrieben haben, fanden das soweit ich weiß auch recht schade, dass die Stringklasse keine Möglichkeit dafür bietet. Ist aber soweit ich weiß fast überall in der STL so. Ich nehme an, ganz einfach weil es nicht dafür gedacht ist durch abgeleitete Klassen erweitert zu werden.

BeRsErKeR hat geschrieben:Funktionieren schon, aber in diesem Fall würde ich ja eigentlich deshalb erben wollen um bestimmte Interfaces nach außen beizubehalten und durch Überladen die Funktionalität an UTF-8 anzupassen.

Also in unserer Diskussion gings eigentlich genau darum dass das Interface von std::string für UTF-8 eben nicht beibehalten werden kann ;)
Wenn du public erben willst, hast du natürlich recht, das wäre eine sehr schlechte Idee, dafür ist die STL nicht gedacht...

dot hat geschrieben:

BeRsErKeR hat geschrieben:Funktionieren schon, aber in diesem Fall würde ich ja eigentlich deshalb erben wollen um bestimmte Interfaces nach außen beizubehalten und durch Überladen die Funktionalität an UTF-8 anzupassen.

Also in unserer Diskussion gings eigentlich genau darum dass das Interface von std::string für UTF-8 eben nicht beibehalten werden kann ;)
Wenn du public erben willst, hast du natürlich recht, das wäre eine sehr schlechte Idee, dafür ist die STL nicht gedacht...

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. Der Index-Operator liefert dir beispielsweise bei identischer Signatur beim Glib::ustring auch wirklich das UTF-8-Zeichen an der n-ten Position und nicht das n-te Byte. Und diesen Operator nutze ich beim std::string (wenn ich es semantisch korrekt mache) halt auch genau zu diesem Zweck. Dass in diesem Fall das n-te Byte auch das n-te Zeichen ist, ist ja eher durch die Größe eine chars bedingt. Übrigens verhält sich std::basic_string<wchar_t> genau in dieser Weise, wodurch nochmal klar wird, dass std::string bzw. std::basic_string<char> nicht für eine UTF-8-Repräsentation verwendet werden sollte. Man verletzt die semantische Bedeutung der Methoden und wenn ich sowas an einen anderen Entwickler weitergebe, hat der wahrscheinlich nicht viel Freude damit.