Ansi / Unicode
-
Guten Tag.
Ich programmiere nun hobbymäßig schon ein wenig länger unnd habe alle Projekte bis jetzt im Unicode-Zeichensatz geschrieben. Ich bin davon ausgegangen, dass Ansi inzwischen "out" ist. Unicode verbraucht zwar 1Byte mehr Speicherplatz pro Zeichen, aber Speicher hat man ja heute genug. Allerdings ist Ansi etwas schneller wenn man längere Zeichenketten bearbeiten will, da weniger Speicher geladen werden muss.
So jedenfalls meine Annahme. Jetzt würde ich aber gerne mal wissen, ob das auch alles stimmt, was ich mir gedacht habe.
Und macht es heute noch Sinn, Ansi Unicode vorzuziehen?Schöne Grüße
-
ANSI ist 1 byte, UNICODE meistens 2. Macht es Sinn char einem int vorzuziehen? Ich glaub dies ist nur eine Frage der Speichereffizienz, eventuell auch Geschwindigkeit. Analog zu Pre-/Post-Increment Operatoren.
Wenn man Komponenten zu bereits bestehenden Programmen schreibt ist man meistens gezwungen, die ANSI oder UNICODE Einstellung von dem Mutterprogramm anzunehmen.
Bin aber gespannt auf weitere Beiträge
-
UNICODE hat gar keine Breite. Und UTF8 ist oft auch nur 1 Byte gross
http://www.joelonsoftware.com/articles/Unicode.html
-
http://en.wikipedia.org/wiki/C%2B%2B11#New_string_literals
Da sind auch noch einmal ein paar Neuerungen zu Stringliteralen (da du ja UTF8 ansprachst, da gibt es 'türlich noch 'n paar andere).
-
Ich sehe das eher umgekehrt, es gibt für mich keinen Grund, Unicode zu verwenden. Da ich keine kommerziellen Produkte schreibe, wo Texte in zig Sprachen übersetzt werden sollen, reicht für mich ASCII völlig aus.
-
@unicoder
Ich würde sagen: Unicode ist 21 Bit breit...
0x00 - 0x10FFFF (oder war's 0x10FFFD?)
-
Okay, also angenommen man entwickelt ein neues Projekt. Dann wäre doch Unicode die bessere Wahl (wenn man Kompatibilität ignoriert)?
@unicoder:
Ja stimmt, aber ich bin jetzt von char und wchar_t unter Windows ausgegangen, deshalb die 1 und 2 Bytes.
-
wchar_t hat beim GCC bei mir unter Mac OS X z.B. 4 Byte.
-
Hab Windows 7, GCC und bei mir sind's zwei
-
Jetzt hätte ich doch mal die Frage, was denn genau der ANSI-Zeichensatz beinhaltet. Ich kenne den genormten ASCII-Satz von 128 Zeichen, ich kenne Unicode mit seinem 1 Millionen Drietindepief Zeichen, UTF-8, wo die Byteanzahl pro Zeichen auf 4 ansteigen kann, jedoch meistens mindestens 8 Bit aufweißt, zahlzeiche 8-Bit-Zeichensätze von ISO-8859-1-15, chinesische, japanische, tibetische, hebräische Zeichensätze, Windows-Codepages und, und, und ... ich habe gedacht, ANSI definiert lediglich, dass 8 Bit verwendet werden.
EDIT: Übrigens stimmt das so nicht ganz, dass Unicode langsamer ist. Der Kernel von Windows arbeitet intern mit Unicode, und bei Multi-Byte muss er umwandeln. Das kostet mehr Laufzeit als die Verwendung von zwei Ocktets (in der Realität kann ein Zeichensatz eh nur 65536 Zeichen abdecken, was anderes habe ich noch nicht gehört).
-
Der aus dem Westen ... schrieb:
(in der Realität kann ein Zeichensatz eh nur 65536 Zeichen abdecken, was anderes habe ich noch nicht gehört).
Und würde höchstwahrscheinlich auch keinen Sinn machen, glaub ich... vllt schon, aber nicht für den Alltagsprogger.
-
Mein MinGW:
`gcc-Version 4.6.1 (GCC)sizeof(wchar_t) == 2`
In den ersten 16 Bit (Unicode) sind praktisch alle derzeit verwendeten Zeichen aller gesprochenen/geschriebenen Sprachen enthalten. D.h. außer für exotische/wissenschaftliche Angelegenheiten reichen Windows' 16-Bit-wchar_ts vollkommen aus.
ANSI-Zeichensatz ist eine ungenaue/falsche Bezeichnung, es gibt mehrere. Wir hier in D verwenden Windows-1252(CP1252)
-
Caligulaminus schrieb:
Mein MinGW:
`gcc-Version 4.6.1 (GCC)sizeof(wchar_t) == 2`
Gleicher Compiler, selbes Ergebnis
Caligulaminus schrieb:
In den ersten 16 Bit (Unicode) sind praktisch alle derzeit verwendeten Zeichen aller gesprochenen/geschriebenen Sprachen enthalten. D.h. außer für exotische/wissenschaftliche Angelegenheiten reichen Windows' 16-Bit-wchar_ts vollkommen aus.
Caligulaminus schrieb:
ANSI-Zeichensatz ist eine ungenaue/falsche Bezeichnung, es gibt mehrere. Wir hier in D verwenden Windows-1252(CP1252)
Was sich aber kein Mensch merken will&kann. Wir sind in Deutschland, also ist ANSI ANSI, Basta.
-
Hacker schrieb:
Und würde höchstwahrscheinlich auch keinen Sinn machen, glaub ich... vllt schon, aber nicht für den Alltagsprogger.
Dank UTF-8 können sich auch Web-Programmierer darauf ausruhen, dass die Zeichen vernünftig dargestellt werden. Habe ich erst heute erfahren, als ich die tibetische Schriftunterstützung für UTF-8 installiert habe. Und Zeichenkompatibilität im Internet ist nun mal wichtig.
-
Hacker schrieb:
Gleicher Compiler, selbes Ergebnis
Gleiche Version?
Edit:
Ach ja...
Was sich aber kein Mensch merken will&kann. Wir sind in Deutschland, also ist ANSI ANSI, Basta.
*hüstel*
-
Erstaunlich wie wenig Leute hier Ahnung von Unicode haben. Unicode hat 0x10FFFF Zeichen (Codepoints). Diese Codepoints können nun auf unterschiedliche Weise in Programmen dargestellt werden. Es gibt einmal UTF-32 (32Bit, 4Byte. wchar_t unter Linux oder char32_t in C++11) dabei werden einfach die Codepoints übernommen und in 32 Bit verpackt. Es gibt aber auch Darstellungen die keine feste Länge nehmen. Einmal UTF-16 (16Bit, 2Byte. wchar_t unter Windows oder char16_t in C++11) bei dem zwei oder vier Bytes zur Darstellung verwendet werden und einmal UTF-8 (8Bit, 1Byte. char) bei dem ein bis vier Bytes zur Darstellung verwendet werden. (Gibt auch noch andere und bei denen mit mehr als ein Byte jeweils noch BE/LE.)
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 11. Zeichen!) Das wird leider von vielen Programmierern nicht beachtet oder verstanden (wie man hier im Thread wieder sieht).
Aber man kann in char, char16_t, wchar_t (egal ob 2 oder 4 Bytes) und char32_t Unicode darstellen!
Wie bereits verlinkt: http://www.joelonsoftware.com/articles/Unicode.html
Ansonsten gibt es im Magazin auch ein Artikel zu dem Thema: http://magazin.c-plusplus.net/artikel/Einf�hrung in Codepages und Unicode
Die Unicode/UTF-8 FAQ: http://www.cl.cam.ac.uk/~mgk25/unicode.htmlSeit Boost 1.48 gibt es dort eine Bibliothek Boost.Locales die einiges an Unicode-Funktionalität anbietet (auf Basis von ICU) http://www.boost.org/libs/locale
Ansonsten gibt es natürlich noch ICU (ist aber sehr hässlich!): http://site.icu-project.org/
-
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