Ansi / Unicode
-
Caligulaminus schrieb:
Hacker schrieb:
Gleicher Compiler, selbes Ergebnis
Gleiche Version?
Jaja, wollte ich auch Schreiben.
Caligulaminus schrieb:
Ach ja...
Was sich aber kein Mensch merken will&kann. Wir sind in Deutschland, also ist ANSI ANSI, Basta.
*hüstel*
Edit: und
rüdiger schrieb:
(char16_t x[] = ...; x[10]; ist nicht das 10. Zeichen!)
Ja, sondern das 11te. (?)
-
rüdiger schrieb:
Bei den variablen Darstellungen muss man natürlich aufpassen, da ein Zeichen nicht einem Element des Strings entsprechen muss. (char16_t x[] = ...; x[10]; ist nicht das 10. Zeichen!) Das wird leider von vielen Programmierern nicht beachtet oder verstanden (wie man hier im Thread wieder sieht).
Meinst du nicht eher 'nicht das elfte Byte'? (Aua) Bei char16_t haben wir 2 Bytes pro Zeichen, machen 24 Bytes für 12 Elemente.
PS: auch die Moderatoren haben es manchmal mit dem Index ...
-
Ich denke rüdiger meinte x[10] ist nicht notwendigerweise das elfte Zeichen. Es könnte z.B. auch das zehnte sein, oder ein low surrogate (zweite Hälfte eines Codepoints > 0x10000). (Abgesehen von dem Flüchtigkeitsfehler im Index natürlich)
-
Hacker schrieb:
Edit: und
rüdiger schrieb:
(char16_t x[] = ...; x[10]; ist nicht das 10. Zeichen!)
Ja, sondern das 11te. (?)
Auch nicht das 11te
Aber Du hast recht. Das kommt davon, wenn man mal mit Programmiersprachen arbeitet, die ab 1 anfangen zu zählen (iiiiih!)@Der aus dem Westen ...
Nein, ich meine das Zeichen. Es geht doch überhaupt nicht um Bytes.
-
rüdiger schrieb:
Hacker schrieb:
Edit: und
rüdiger schrieb:
(char16_t x[] = ...; x[10]; ist nicht das 10. Zeichen!)
Ja, sondern das 11te. (?)
Auch nicht das 11te
Aber Du hast recht. Das kommt davon, wenn man mal mit Programmiersprachen arbeitet, die ab 1 anfangen zu zählen (iiiiih!)Welche denn? Ich muss die Erfinder lynchen
-
Da die Zeichen unterschiedlich lang sein können (bei UTF-16 eben 2 oder 4 Byte) mußt Du, um sicherzugehen, von Anfang an durchzählen...
EDIT:
Ah! Du beziehst dich auf die Programmiersprache(?)... Ich glaube, FORTRAN ist so ein Kandidat.
-
Ui, ich wusste nicht, dass UTF-16 auch 4 Bytes zur Darstellung verwenden kann. Wieder was gelernt.
Dann ergibt das auch Sinn. 10 kann dann alles mögliche sein, sogar mitten in einem Zeichen anfangen.
-
Es wird sogar noch interessanter. Selbst bei UTF-32, wo alle Codepoints in 32 Bit dargestellt werden, ist
char32_t x[] = ...; x[10];nicht unbedingt das 11. Zeichen. Der Begriff "Zeichen" ist halt ein bisschen schwammig (und wird daher im Unicode Standard nicht verwendet). Bei UTF-32 ist x[10] zwar der 11. Codepoint. Aber es gibt auch noch kombinierende Zeichen (http://en.wikipedia.org/wiki/Combining_character). Die haben jeweils ihren eigenen Codepoint. Aber werden zusammengesetzt dargestellt. Wenn man also mit Zeichen das Graphem meint, dann ist man auch bei UTF-32 in Schwierigkeiten und muss die vorhergehenden/nachfolgenden Codepoints anschauen. Noch komplizierter wird es, wenn man bedenkt das ein Graphem auf unterschiedliche Weise dargestellt werden kann (zB kann man Ä als Ä oder als ̈A (mit Combining Characters) darstellen). Deshalb braucht man dann noch Normalisierung.
-
Ich glaube, NT hat noch UCS-2 verwendet. Da konnte man sich mit sowas noch auf der sicheren Seite fühlen. Mit UTF-16/8 fährt man da schnell gegen die Wand. Wobei (wie oben schon erwähnt) in 16 Bit eigentlich alles (weltweit) gängige abgebildet ist. Das Risiko mit der Wand ist hier also sehr gering - aber trotzdem da.
Und dann gibt es ja noch zusammengesetzte Zeichen, womit meine Relativierung eben (die mit dem geringeren Risiko) wieder hinfällig wäre. (gilt auch für UCS-2)Edit:
2 Minuten! Mann bin ich langsam...PPS: Ich glaube, es ist: A ̈ == Ä
-
Hui, so genau wollte ich das garnicht wissen
Also, so hab ich das jetzt verstanden, ist "Unicode" heute Ansi vorzuziehen, korrekt?
Ich gehe dabei von einem neuen Projekt aus, welches nicht mit einem anderen kompatibel sein muss und bei dem die Geschwindigkeit egal ist.