In welcher Zeichenkodierung speichert ihr eure Quellcodedateien ab?
-
Als ISO 8859-* Text oder als UTF-8?
Und wie schreibt ihr Umlaute?
Schreibt ihr die grundsätzlich als äöü oder umschreibt ihr diese als ae, oe, ue,
so dass jedes Zeichen in eurer Quellcodedatei grundsätzlich ohne Datenverlust auch in 7-Bit ASCII Textkodierung dargestellt werden könnte??Ich würde mal vermuten, dass der Compiler beim compilieren langsamer mit dem interpretieren des Quellcodes ist, wenn man UTF-8 verwendet.
Ist meine Vermutung hier korrekt?Die Frage bezieht sich auf C und C++ Quellcode.
Das in Java UTF-8 oder Textbeschreibungssprachen wie HTML UTF-8 sinnvoller ist, dürfte klar sein. Nur bei C oder C++ Quellcode braucht man das nicht wirklich, wenn Daten des Programms zur Informationsdarstellung vom Quellcode getrennt und in eigene Dateien (z.B. XML) ausgelagert sind.
-
UTF-8, äöü.
UTF-8 schrieb:
Ich würde mal vermuten, dass der Compiler beim compilieren langsamer mit dem interpretieren des Quellcodes ist, wenn man UTF-8 verwendet.
Ist meine Vermutung hier korrekt?LOL. Du lässt wohl auch Kommentare weg und wählst nur einbuchstabige Bezeichner
.
-
SeppJ schrieb:
UTF-8 schrieb:
Ich würde mal vermuten, dass der Compiler beim compilieren langsamer mit dem interpretieren des Quellcodes ist, wenn man UTF-8 verwendet.
Ist meine Vermutung hier korrekt?LOL. Du lässt wohl auch Kommentare weg und wählst nur einbuchstabige Bezeichner
.Das hat mit dem einen nichts zu tun.
Bei UTF-8 kann ein Zeichen 1 bis 4 Byte sein, dass muss also der Parser berücksichtigen und das bremst ihn ganz sicher mehr aus, als eine Quellcodedatei bei der ein Zeichen nicht größer als 1 Byte ist.
-
Der Parser bekommt doch schon fertige Tokens vom Lexer, inwiefern muss der die Länge des Bezeichners feststellen? Jedenfalls ist Compile-Time sowieso kein Kostengrund mehr und der Unterschied der durch UTF-8 vs. ISO-8859-1 theoretisch, wenn überhaupt, entstehen könnte, ist in Zeiten von 2min Full-Compile-Time und 10h Integrations-Tests sowieso hinfällig.
Die Frage an sich würde ich daher abstempeln, alles andere als UTF-8 ist imho keine gute Idee, auch wenn Kommentare und Code schön brav in ASCII gehalten sein sollten macht UTF-8 das Kraut hier nicht fett.
Wäre nur noch schön zu sehen wenn die ganze Welt auf UTF-8 umsteigt. http://www.utf8everywhere.org/
MfG SideWinder
-
Quellcode ist immer reines ASCII. In meinem Quellcode kommen keine Umlaute vor. Kommentare schreibe ich in Englisch. Da kommen keine nicht-ASCII-Zeichen vor. Die einzige Stelle, wo ein Umlaut eigentlich hingehört ist in meinem Namen. Und da verwende ich ae.
ASCII ist gültiges UTF-8. Und dem Parser ist das wirklich egal.
Wenn ich mir da um Compilezeit Gedanken machen würde, könnte ich die Kommentare weg lassen und Bezeichner möglichst kurz wählen. Und mit whitespace sparsam umgehen. Dann hat der Compiler weniger bytes zu lesen. Ist auf jeden Fall schneller. Aber selbst bei Compilezeiten im Stundenbereich würde man da nur Bruchteile von Sekunden einsparen.
-
SideWinder schrieb:
Der Parser bekommt doch schon fertige Tokens vom Lexer, inwiefern muss der die Länge des Bezeichners feststellen?
Aber Lexer und Präprozessor sind langsamer, wenn der Quellcode länger ist. Für jemanden, der bei UTF-8 vs. ASCII relevante Geschwindigkeitsunterschiede heraufbeschwört, ist dieser Unterschied wichtig.
tntnet schrieb:
Quellcode ist immer reines ASCII. In meinem Quellcode kommen keine Umlaute vor. Kommentare schreibe ich in Englisch. Da kommen keine nicht-ASCII-Zeichen vor. Die einzige Stelle, wo ein Umlaut eigentlich hingehört ist in meinem Namen. Und da verwende ich ae.
ASCII ist gültiges UTF-8.
Ich sollte wohl noch erwähnen, dass ich das selbstverständlich auch so halte, nicht das ein falscher Eindruck entsteht. Aber der Editor ist darauf eingestellt UTF-8 zu benutzen (auch wenn ich nur die ASCII-Untermenge nutze) und ich hätte auch kein Problem mit einem 'ä' im Quelltext, wenn ich es bräuchte.
-
Interessant wird das eh erst, wenn der Compiler auch die C++11 UTF-Literale unterstützt.
-
SeppJ schrieb:
tntnet schrieb:
Quellcode ist immer reines ASCII. In meinem Quellcode kommen keine Umlaute vor. Kommentare schreibe ich in Englisch. Da kommen keine nicht-ASCII-Zeichen vor. Die einzige Stelle, wo ein Umlaut eigentlich hingehört ist in meinem Namen. Und da verwende ich ae.
ASCII ist gültiges UTF-8.
Ich sollte wohl noch erwähnen, dass ich das selbstverständlich auch so halte, nicht das ein falscher Eindruck entsteht. Aber der Editor ist darauf eingestellt UTF-8 zu benutzen (auch wenn ich nur die ASCII-Untermenge nutze) und ich hätte auch kein Problem mit einem 'ä' im Quelltext, wenn ich es bräuchte.
Wie Du Deinen Editor einstellst ist herzlich egal. Wenn nur ASCII verwendet wird, kommt eh das gleiche raus. Na ja - EBCDIC darf man nicht verwenden. Wenn im Kommentar ein ä mit ISO-8859-1-Kodierung oder UTF-8-Kodierung vorkommt, wird der Compiler beides sicher ignorieren. Also auch dann wäre es egal.
-
Ich verwende Codepage 1252 (Fast ISO 8859-1). Das scheint der Default zu sein, habe ich nie was dran geändert und sehe auch keinen Grund dies zu tun.
Ich verwende Umlaute in Literalen, finde es Userfeindlich Ihm verstümmelte Umlaute vorzusetzen.
-
BadWolf schrieb:
Ich verwende Codepage 1252 (Fast ISO 8859-1). Das scheint der Default zu sein, habe ich nie was dran geändert und sehe auch keinen Grund dies zu tun.
wenn du Sonderzeichen verwendest (fängt mit dem €-Zeichen schon an), hast du einen Grund
CP1252 ist eine Mischung aus ISO-8859-1 und ISO-8859-15. Der für deutsche relevante Unterschied ist beim €-Zeichen, das in keiner dieser Codierungen an der richtigen Stelle sitzt (richtig aus Sicht von Unicode).
Irgendwann brauchst du dann doch mehr als CP1252 und dann wirds lustig
-
UTF-8 schrieb:
Das hat mit dem einen nichts zu tun.
Bei UTF-8 kann ein Zeichen 1 bis 4 Byte sein, dass muss also der Parser berücksichtigen und das bremst ihn ganz sicher mehr aus, als eine Quellcodedatei bei der ein Zeichen nicht größer als 1 Byte ist.Netterweise hat UTF-8 aber die Eigenschaft dass man bei den meisten Dingen komplett ignorieren kann dass es ein Multi-Byte-Encoding ist. z.B. wenn du einen String in Tokens splitten willst, und die Split-Chars alle Codepoints <= 127 sind, dann kannst du das mit UTF-8 genau gleich machen wie man es auch mit Latin-1 oder einem anderen Single-Byte Encoding machen würde.
Und wenn der Compiler Unicode-Literals unterstützen soll o.ä., dann braucht er sowieso irgend ein Unicode-Encoding. Kann er gleich UTF-8 nehmen, anstatt Platz für UTF-16 zu verschwenden (ohne besonderen Vorteil, weil UTF-16 genau so ein variable Length Encoding ist).
Und UTF-32 wäre dann wohl doch etwas Overkill. Würde ziemlich sicher alles nur langsamer machen, wegen Platzverbrauch im Cache und so.
-
wenn du Sonderzeichen verwendest (fängt mit dem €-Zeichen schon an), hast du einen Grund
CP1252 ist eine Mischung aus ISO-8859-1 und ISO-8859-15. Der für deutsche relevante Unterschied ist beim €-Zeichen, das in keiner dieser Codierungen an der richtigen Stelle sitzt (richtig aus Sicht von Unicode).
Irgendwann brauchst du dann doch mehr als CP1252 und dann wirds lustig
Hmm, ich verwende das Euro-Zeichen laufend (Ich schreibe Finanzsoftware). Ich hatte damit noch nie Probleme. Und wenn ich Tatsächlich mal Unicode brauche (war bisher nur bei Benutzung eines API's vonnöten, das Strings in UTF-16 erwartet) hat auch MultiByteToWideChar() keine Probleme mit dem Euro-Zeichen.
Von daher, wie gesagt, ich hatte bisher keinen Grund auf UTF8 zu gehen. Ich sollte dazu vielleicht noch sagen, dass mir Linux am Arsch vorbei geht, das könnte vielleicht ein Grund sein, warum mir das Euro-Zeichen keine Probleme bereitet...
-
die Antwort hängt ja von der Programmiersprache ab - in C/C++ (da brauche ich nie mehr als 7 bit) kann die Antwort ganz anders aussehen als etwa in APL
-
BadWolf schrieb:
Von daher, wie gesagt, ich hatte bisher keinen Grund auf UTF8 zu gehen. Ich sollte dazu vielleicht noch sagen, dass mir Linux am Arsch vorbei geht, das könnte vielleicht ein Grund sein, warum mir das Euro-Zeichen keine Probleme bereitet...
Du meinst nicht nur Linux, sondern praktisch jedes andere Betriebssystem außer Windows. Bei deiner Finanzsoftware kannst du die vielleicht ignorieren, andere können das nicht.
UTF-8 ist in dieser Hinsicht einfach genial. Es ist simpel und dabei sehr gut durchdacht.
-
Rotk¤ppchen: Klasse Name
-
BadWolf schrieb:
Von daher, wie gesagt, ich hatte bisher keinen Grund auf UTF8 zu gehen. Ich sollte dazu vielleicht noch sagen, dass mir Linux am Arsch vorbei geht, das könnte vielleicht ein Grund sein, warum mir das Euro-Zeichen keine Probleme bereitet...
Ich finde es respektlos, wenn jemand solche Kraftausdrücke verwenden muss. Wirklich schade.
Dennoch wollte ich hier mal anmerken, dass es unter Linux keine Probleme mit dem Euro-Zeichen gibt. Moderne Linuxe wie auch andere Betriebssysteme arbeiten mit UTF-8. Ich habe schon seit Jahren keine Probleme mehr mit Sonderzeichen gehabt. Und Windows verwende ich zu Hause wahrscheinlich genau soviel wie Du Linux.
-
SideWinder schrieb:
in Zeiten von 2min Full-Compile-Time
Was für Kindergartensoftware ist das?
