Was machen Programmier-Anfänger mit ihren Fragen?

[RobertDebiannutzer]

@novalix:
"Working Code" ist insbesondere bei einem Anfänger keine absolute Feststellung. Und irgendwo muss man seine Frage ja posten. Hier im debianforum habe ich ja auch bereits wieder viele hilfreiche Anregungen bekommen. Und auch die Antwort von dem User bei stackexchange war ja hilfreich, doch erst mit ein wenig Erklärung.
"Lästig" ist mir Kritik nie, dass mein Verständnis "löchrig" ist, ist ja eh klar, wie könnte es auch anders sein. Man kann ja nie gleich alles wissen. Dafür muss sich doch niemand schämen! Vielleicht ist man manchmal kurz enttäuscht, dass noch nicht alles richtig ist, aber diese Enttäuschung weicht ja schnell der Freude, wenn es dann besser wird!

Zu meiner Funktion:
Ich habe jetzt bald beide Ansätze soweit. Warum doch wieder beide?

Der Hase liegt dort im Pfeffer, wo über die Continuation Bytes eines Multibyte-Encodings zurückgeloopt wird.

Das stimmt nicht ganz, denn das Problem kann ich - glaube ich - lösen, wenn ich mich einfach auf den Rückgabewert von mblen verlasse statt auf mein Macro "ISCB" (welches ich geschrieben hatte, um Continuation Bytes zu entdecken, was aber nur bei UTF-8 funktioniert). Der Rückgabewert von mblen ist nämlich -1, wenn ein Continuation Byte vorliegt. Denn Zitat manpage mblen:

If the n bytes starting at s do not contain a complete multibyte character, mblen() returns -1.

Dann sieht das quasi so aus:

Code: Alles auswählen

		/* loop to begin of character */
		while ((r = mblen(s1, MB_LEN_MAX)) < 0) { s1--; };
		memcpy(u1, s1, r);
		u1[r] = '\0';
		/* loop to begin of character */
		while ((r = mblen(s2, MB_LEN_MAX)) < 0) { s2--; };
		memcpy(u2, s2, r);
		u2[r] = '\0';

(Noch ohne die vielleicht nötige Fehlerbehandlung.)

[RobertDebiannutzer]

So, einmal der "alternative approach" (loop bis Zahl, schauen, ob alles bis dahin gleich ist, danach Zahlen verarbeiten, schauen, ob sich da eine differenz ergibt, ansonsten weiter): 40534
und einmal mein doch wieder präferierter Ansatz (loop bis sich eine differenz ergibt, dann handeln): 40533.
(Beide Funktionen sind mit einer kleinen main() und zwei Test-Funktionen. Kompiliert wurde beides auf Debian 9 mit "gcc -pedantic -Wall -Wextra".)
Den eingebauten Performance-Test kann man mit dem bash-Builtin "time" (oder dem separaten Programm "time") verwenden.
Ergebnisse:
für den "alternative approach": ca. 6.0 Sekunden
für meinen präferierten Ansatz: ca. 1.7 Sekungen.

Fehlerhandling sieht so aus, dass die Funktion 0 zurückgeben soll, wenn es einen Fehler gab.

Eine Schwachstelle könnte mblen sein, wenn das Encoding fehlerhaft ist oder irgendetwas anderes (?) ist und mblen ständig -1 herausgibt. Ich habe versucht, unter Berücksichtigung dessen Buffer Overflows o.ä. zu verhindern.

Was meint ihr?

[Meillo]

Den eingebauten Performance-Test kann man mit dem bash-Builtin "time" (oder dem separaten Programm "time") verwenden.
Ergebnisse:
für den "alternative approach": ca. 6.0 Sekunden
für meinen präferierten Ansatz: ca. 1.7 Sekungen.

Da ist ca. Faktor 4. (Also aus Zeitperformance-Optimierungs-Sicht gering.)

Du testest 8 Eintraege (manche einfach, manche komplex) 1 Mio Mal.

Wenn man ein grosses Verzeichnis mit 1000 Eintraegen nimmt, dann waeren das in einem realen Anwendungsfall im Filemanager rein rechnerisch 0,0008s vs. 0,0002s -- also voellig egal.

Was sagt dieser Performance-Test also aus? Nichts. (Oft sind am Ende irgendwelche Overheads oder IO-Operationen dann eh nochmal groesser als die ganze Berechnung selbst.) Du stellst die Performance-Messung hier in den Raum, wie wenn sie eine Aussagekraft haette.

Ich bin nicht der erste, der empfiehlt, auf die Zeit- und Speicher-Performance zuletzt zu schauen. Achte zuerst auf die Programmier- und Debug-Performance, die ist viel wichtiger. Erst wenn's am Ende zu langsam sein sollte, dann nimm einen Profiler und schau, *was* zu langsam ist, bevor du deinen Code unleserlich machst.


Btw: Auch wenn du nun scheinbar zwei verschiedene Verfahren verwendest, so ist der Code doch beidesmal gleich unleserlich. Meine Empfehlung waere, nochmal ganz frisch und zwar Top-Down anzufangen, also etwa in der Art:
1. Leere function mycmp()
2. Darin enthalten: While-Schleife die den String in Chunks mit nur Ziffern oder nur Nicht-Ziffern zerlegt (Das Zerlegen evtl. in separater Funktion)
3. Fuer jeden Chunk wird die passende Hilfscomparefunktion aufgerufen (separate Funktion
4. ...

Und schon hast du dein Problem zerteilt, hast mehrere kleine Funktionen, die jeweils nur eine kleine Teilaufgabe machen. Damit wird das ganze lesbarer werden.

[RobertDebiannutzer]

Danke für die klare Rückmeldung!

Ich wollte die neue Funktion gleich mitbringen, aber ich habe noch Probleme mit dem Vergleich meiner beiden Zahlen-Sequenzen. Wo kann ich eigentlich herausfinden, ob Zahlen immer Einzelbytes sind bzw. ob man die dann auch ganz einfach mit ">" "<" vergleichen kann?

Was ich noch gerne fragen wollte: Was genau macht Code wie den in meinen obigen Funktionen eigentlich unleserlich? Ist das dahinterstehende Konzept nicht klar genug oder schlecht, oder ist der Code von der Syntax her nicht strukturiert genug, oder was genau ist es?

[eggy]

a) Die Länge der Funktionen. Siehe weiter oben im Thread
b) Unnötig kompliziertes if/elseif

Code: Alles auswählen

 if (argc == 3) {
                printf("%d\n", mycompare(argv[1], argv[2]));
                exit(EXIT_SUCCESS);
        } else if (argc == 2 && strcmp(argv[1], "--debug") == 0) {
              [...]                   
                exit(EXIT_SUCCESS);
        } else if (argc == 2 && strcmp(argv[1], "--perftest") == 0) {
              [...]

lesbarer wäre:

Code: Alles auswählen

    if (argc == 3) {
                printf("%d\n", mycompare(argv[1], argv[2]));
                exit(EXIT_SUCCESS);
        }
        
    if (argc == 2 && strcmp(argv[1], "--debug") == 0) {
              [...]                   
                exit(EXIT_SUCCESS);
    }
    
    if (argc == 2 && strcmp(argv[1], "--perftest") == 0) {
              [...]

Jede der Teilfunktionen, die mit exit oder return endet würde ich alleine stehen haben. In diesen Fällen ist es semantisch äquivalent die Funktionen auseinanderzuziehen. Erhöht die Lesbarkeit gleich ungemein.

c) Es fehlen Headerfiles. Sie ermöglichen ein schnelles Überfliegen "was ist in der Datei, welche Funktionen gibt es", man kann sich gedanklich auf den Code vorbereiten, hat praktisch eine "Karte", wo es langgehen wird, wenn man den restlichen Code liest.

Edit: Typo

[ViNic]

Also ich würde die Benennung der Variablen bemängeln, die Einrückungen im Code und das Code anscheinend doppelt vorhanden ist.

Ist aber nur meine Meinung.

[Meillo]

Ich wollte die neue Funktion gleich mitbringen, aber ich habe noch Probleme mit dem Vergleich meiner beiden Zahlen-Sequenzen. Wo kann ich eigentlich herausfinden, ob Zahlen immer Einzelbytes sind bzw. ob man die dann auch ganz einfach mit ">" "<" vergleichen kann?

Du koenntest auch einfach mit strtol(3) vergleichen, dann bekommst du auch gleich das Suchen des Zahlenendes geschenkt (bloss wuerde das sowas wie ``1234e-56'' als eine Zahl interpraetieren ...). Die Ziffern sind alle Teil von US-ASCII, insofern kannst du die auch direkt vergleichen, aber ...

Was ich noch gerne fragen wollte: Was genau macht Code wie den in meinen obigen Funktionen eigentlich unleserlich? Ist das dahinterstehende Konzept nicht klar genug oder schlecht, oder ist der Code von der Syntax her nicht strukturiert genug, oder was genau ist es?

... genau das macht Code unleserlich, Low-Level-Code, der Bytes vergleicht. Der Grund ist, dass er nur schwer erkennen laesst, was *inhaltlich* gemacht wird. Wenn du also nicht strtol(3) verwendest, dann schreibe dir selber eine strnumcmp() oder so, die zwei Strings entgegen nimmt und die in ihnen enthaltenen Zahlen vergleicht.

Code wird beispielsweise lesbarer, wenn jede Funktion nur auf einem Abstraktionslevel arbeitet. Die eine Funtion arbeitet auf Bytes, die darueber auf Chunks von Strings, die darueber auf ganzen Strings. Sowas hilft.

Ansonsten sei auf den Telefontest verwiesen. (Siehe dazu auch: viewtopic.php?f=34&t=165425 )

Wenn du ein Buch lesen willst, dann ist meine beste Empfehlung: ``The Practice of Programming'' von Kernighan und Pike.

[RobertDebiannutzer]

Danke für eure Anregungen!

Du koenntest auch einfach mit strtol(3) vergleichen[…]

Dann kann die Zahlenfolge aber nicht beliebig lang sein, oder?

Die Ziffern sind alle Teil von US-ASCII, insofern kannst du die auch direkt vergleichen […]

Also auch bei irgendeinem anderen Encoding und sogar in der Form (a == '0') (nach geeignetem setlocale() natürlich)? Wenn ja, ist das toll, so habe ich die neue Funktion auch einfach mal verfasst. Allerdings habe ich dann das mit den Encodings noch nicht ganz verstanden...
Vielen Dank übrigens für die Buch-Empfehlung, hört sich sehr interessant an!

c) Es fehlen Headerfiles. Sie ermöglichen ein schnelles Überfliegen "was ist in der Datei, welche Funktionen gibt es", man kann sich gedanklich auf den Code vorbereiten, hat praktisch eine "Karte", wo es langgehen wird, wenn man den restlichen Code liest.

Ja, bei einem "ganzen" Programm mache ich auch immer eine schöne Header-Datei, in der ich auch die globalen Variablen kurz erkläre (habe ich mir von Linus Torvalds uemacs abgeschaut...). Aber ich habe jetzt mal alle Funktionen ganz oben separat deklariert.

Ich habe versucht, alle eure Kommentare zu berücksichtigen und den von @meillo vorgeschlagenen Ablauf so gut ich konnte einzuhalten:
40535
Zeile 93 ist vielleicht noch etwas kompliziert...
Was dort passiert:
--------------
wenn len1 == 0 und i == 0, dann ist s1 größer, deshalb len2-len1
wenn len1 == 0 und i > 0, dann ist s2 größer, deshalb len1-len2
wenn len2 == 0 und i == 0, dann ist s2 größer, deshalb len2-len1
wenn len2 == 0 und i > 0, dann ist s1 größer, deshalb len1-len2
-------------
Vielleicht sollte man sowas im Code doch weiter auseinanderpflücken? Allerdings sieht es so als ein if wenn man es mal durchschaut hat übersichtlicher aus...

[eggy]

Code: Alles auswählen

int
main(int argc, char *argv[])
{

Der Typ des Rückgabewerts gehört in C und vielen anderen Sprachen mit zur Signatur. Daher sollte er mit dem Rest der Signatur auf einer Zeile sein.

Code: Alles auswählen

int main(int argc, char *argv[]) {

Dass Du die Klammern auf der nächsten Zeile setzt, ist hingegen reine Geschmackssache. Ich finde öffnende Klammer auf neuen Zeilen absolut fürchterlich, für mich gehören die ans Ende der Zeile. Macht es aus meiner Sicht dann auch wieder nen ganzes Stück schneller lesbar. Aber wie gesagt, der Teil ist Geschmackssache.

[Meillo]

Du koenntest auch einfach mit strtol(3) vergleichen[…]

Dann kann die Zahlenfolge aber nicht beliebig lang sein, oder?

Korrekt erfasst. Daran habe ich nicht gedacht.

Die Ziffern sind alle Teil von US-ASCII, insofern kannst du die auch direkt vergleichen […]

Also auch bei irgendeinem anderen Encoding und sogar in der Form (a == '0') (nach geeignetem setlocale() natürlich)?

AFAIK sind in jedem bekannten Locale die Ziffern 0-9 aufsteigend direkt hintereinander. Du kannst zwei Ziffern also anhand ihrer Character-Values vergleichen und bekommst die nummerisch korrekten Ergebnisse.

Bloss mit sowas wie UTF-16 kenne ich mich nicht aus.

[Meillo]

Code: Alles auswählen

int
main(int argc, char *argv[])
{

Der Typ des Rückgabewerts gehört in C und vielen anderen Sprachen mit zur Signatur. Daher sollte er mit dem Rest der Signatur auf einer Zeile sein.

Code: Alles auswählen

int main(int argc, char *argv[]) {

Dass Du die Klammern auf der nächsten Zeile setzt, ist hingegen reine Geschmackssache. Ich finde öffnende Klammer auf neuen Zeilen absolut fürchterlich, für mich gehören die ans Ende der Zeile. Macht es aus meiner Sicht dann auch wieder nen ganzes Stück schneller lesbar. Aber wie gesagt, der Teil ist Geschmackssache.

Ersteres ist aber ein durchaus verbreiteter Stil in C.

K&R schreiben die oeffnende geschweifte Klammer bei Funktionen (nur da!) auch auch in eine neue Zeile. Der vi beruecksichtigt das auch, denn da kann man mit [[ und ]] dann von Funktion zu Funktion springen.

Historisch gesehen gab es in Pre-ANSI-C keine Rueckgabetypangaben und die Argumenttypen wurden *zwischen* die Funktionssignatur und die oeffnende geschweifte Klammer geschrieben. Darum ist die oeffnende geschweifte Klammer in einer extra Zeile.

Den Rueckgabetyp in eine extra Zeile zu schreiben hat den schoenen Vorteil, dass man dann mit der RegExp /^foo(/ direkt zur Definition der Funktion foo springen kann. K&R machen das so zwar nicht, ich mache es aber gerne so. Ausserdem ist es hilfreich, wenn man komplexe Typen zurueckliefert und viele Argumente mit komplexen Typen hat, weil man sich dann oft Umbrueche auf 80 Columns spart. (Und man muss den Funtionsnamen nicht suchen, wenn man ohne Syntax-Highlighting arbeitet.)

Wie du schreibst, ist manches Geschmackssache. Fuer manches gibt es Begruendungen die im einen oder anderen Fall relevant sind. Wie man es auch macht, man sollte begruenden koennen, warum man es so macht und nicht anders. (Eine Begruendung waere, dass die Programmiercommunity in der man sich bewegt es so macht und man sich ihr anpasst.)

[tobo]

Der Typ des Rückgabewerts gehört in C und vielen anderen Sprachen mit zur Signatur. Daher sollte er mit dem Rest der Signatur auf einer Zeile sein.

Das ist genauso Geschmacksache. Zwei z.B., die das anders sehen:
https://www.gnu.org/prep/standards/standards.html
https://suckless.org/coding_style/

PS: Diese Anzeige, dass da inzwischen ein weiterer Beitrag war, scheint aber auch nicht immer zu funktionieren!?

[novalix]

(sorry für OT)

PS: Diese Anzeige, dass da inzwischen ein weiterer Beitrag war, scheint aber auch nicht immer zu funktionieren!?

Das scheint immer dann nicht zu funktionieren, wenn man den "Vorschau"-Modus benutzt hat.

[RobertDebiannutzer]

AFAIK sind in jedem bekannten Locale die Ziffern 0-9 aufsteigend direkt hintereinander. Du kannst zwei Ziffern also anhand ihrer Character-Values vergleichen und bekommst die nummerisch korrekten Ergebnisse.

Ok, aber sind das auch immer Singlebytes? Sowas muss doch irgendwo stehen. Für Unicode habe ich nun das hier gefunden: https://en.wikipedia.org/wiki/Compariso ... #In_detail . Demnach müsste ich den Loop über die Zahlen doch umschreiben, da doch nicht eine Zahl = ein Byte gilt.

Zum Style:
Ich schreibe bei Funktionen immer Rückgabewert und geschweifte Klammer in eine separate Zeile, da ich es viel übersichtlicher finde. (Ich nutze auch kein syntax highlighting, außer für Kommentare). Gerade, wenn eine Funktion viele Argumente entgegennimmt, ist die Klammer auf der nächsten Zeile sehr gut, da dann Freiraum ist zwischen der Liste der Argumente und den Deklarationen der Variablen. Außerdem möchte ich immer gerne unter 81 Columns bleiben, da das angenehmer ist, wenn man zwei Dateien nebeneinander bearbeitet (tiling window manager / split screen in vim).

@meillo: Als ich gestern nach einem "Blick ins Buch" von "The Practice of Programming" suchte, habe ich u.a. das hier gefunden: https://www.oreilly.com/library/view/th ... /ch01.html . Das Zitat kenne ich sogar, denn "The Elements of Style" von William Strunk (https://en.wikipedia.org/wiki/The_Elements_of_Style) habe ich sogar als Buch bzw. eher Heft. (Eine hübsche neuere Ausgabe, die ich mal in einer Buchhandlung gefunden habe, da ich dort immer auch nach versteckten kleinen Büchlein schaue. Die Buchhändlerin wusste gar nicht, dass sie das hatte, und hat den Preis nicht mehr im Computer gefunden, deshalb habe ich es sogar geschenkt bekommen. )

[Meillo]

AFAIK sind in jedem bekannten Locale die Ziffern 0-9 aufsteigend direkt hintereinander. Du kannst zwei Ziffern also anhand ihrer Character-Values vergleichen und bekommst die nummerisch korrekten Ergebnisse.

Ok, aber sind das auch immer Singlebytes? Sowas muss doch irgendwo stehen. Für Unicode habe ich nun das hier gefunden: https://en.wikipedia.org/wiki/Compariso ... #In_detail . Demnach müsste ich den Loop über die Zahlen doch umschreiben, da doch nicht eine Zahl = ein Byte gilt.

In UTF-16 ist es natuerlich kein Single-Byte, weil dort alle Zeichen zwei Bytes haben. (Aber mit solchen Sackgassentechnologien beschaeftige ich mich nicht darum kann ich dazu nichts sagen.)

@meillo: Als ich gestern nach einem "Blick ins Buch" von "The Practice of Programming" suchte, habe ich u.a. das hier gefunden: https://www.oreilly.com/library/view/th ... /ch01.html . Das Zitat kenne ich sogar, denn "The Elements of Style" von William Strunk (https://en.wikipedia.org/wiki/The_Elements_of_Style)

``The Elements of Style'' wird in mehreren der Computerbuecher von den Autoren um Kernighan erwaehnt. Die Denkweisen passen auch gut zusammen (``Omit needless words!'' ). Sozusagen der Vorlaeufer von ``The Practice of Programming'' (1999) ist ``The Elements of Programming Style'' (1974) von Kernighan und Plauger. Das ist nicht nur vom Titel angelehnt. Allerdings kommt das noch aus der Fortran-Zeit. Man braucht schon ein bisschen historischen Background, wenn man das mit Vergnuegen lesen will. Das Buch von 1999 ist sozusagen die moderne(re) Verarbeitung des gleichen Themas.

[RobertDebiannutzer]

Aber mit solchen Sackgassentechnologien beschaeftige ich mich nicht

Möchtest Du damit andeuten, dass ich Multi-Byte-Zahlen einfach erstmal in die "Limitations"-File* schreiben soll? Weil ASCII, UTF-8, dieses Latin1 und viele andere scheinen ja die Zahlen als Single-Bytes zu implementieren.
Manchmal ist es bei so Sondersachen etwas schwierig, finde ich, mit der Entscheidung, ob man sie umsetzt oder nicht. Sie dauern am längsten beim Programmieren und man läuft Gefahr, dass einer der folgenden Fälle eintritt:
1) man gibt auf (kann mir eher nicht passieren)
2) der ganze Code wird schlecht, hat aber dafür Unterstützung für 0,001% der Anwendungsfälle
3) es hat kein einziger der künftigen User gebraucht

*In der steht übrigens noch nichts, denn mein file manager kann mit Pfadlängen > PATH_MAX umgehen, das habe ich getestet. (Einzig bei symbolischen Links bin ich mir noch nicht ganz sicher...)

[Meillo]

Aber mit solchen Sackgassentechnologien beschaeftige ich mich nicht

Möchtest Du damit andeuten, dass ich Multi-Byte-Zahlen einfach erstmal in die "Limitations"-File* schreiben soll? Weil ASCII, UTF-8, dieses Latin1 und viele andere scheinen ja die Zahlen als Single-Bytes zu implementieren.

Ich bin der Meinung, dass alle Encodings ausser UTF-8 Sackgassen sind. Sie haben mehr Nachteile als Vorteile gegenueber UTF-8. Gerade UTF-16 ist einfach nur schrecklich: Man hat Byte-Order-Probleme, die es bei UTF-8 nicht gibt. Man kann zwar ein paar Zeichen ein bisschen effizienter kodieren als mit UTF-8, die fast haeufigsten Zeichen aber ineffizienter. Reine CJK-Texte sind in UTF-8 zwar groesser als in UTF-16, aber das umfasst nur ein Drittel weniger Platzverbrauch, der nur bei einem Viertel aller Zeichen vorhanden ist. UTF-8 kann auch mehr Zeichen kodieren, als UTF-16. Derzeit wird das nicht genutzt, aber es existiert Raum zur Erweiterung (ohne dass man Sonderfaelle einfuehren muesste). UTF-8 hat eine viel bessere Robustheit, beim Uebertragungsfehlern.

In Summe: UTF-16 schafft durch seine Existenz mehr Probleme als es loest. Es waere besser gewesen, es haette es nie gegeben ... dann haette man es gleich richtig machen koennen, naemlich mit UTF-8.


... nun gut, UTF-9 ist das einzige andere Encoding, das ich noch gelten lasse: https://tools.ietf.org/html/rfc4042



Zum Thema: Was du in deinem speziellen Fall machen sollst, kann ich nicht sagen. Direktes Rumwerkeln mit Bytes wird dir immer Inkompatibilitaeten mit irgendwelchen Encodings einhandeln. Da musst du selber entscheiden was dir wichtiger ist. Ich fuer mich wuerde sagen: Vergiss alle Zeitperformance und nutze Bibliotheksfunktionen, die dieses ganze Encoding-Zeugs fuer dich uebernehmen. Wenn das dann alles korrekt funktioniert, dann baust du es in deine Anwendung ein und dann erst schaust du mal, ob es wirklich zu langsam ist.

... andererseits lernst du auf dem Weg sicher nicht so viel ueber Encodings.

Btw: https://ulm.ccc.de/ChaosSeminar/2016/10 ... oding-font

[RobertDebiannutzer]

Vergiss alle Zeitperformance […]

An die habe ich jetzt auch wirklich gerade nicht mehr gedacht!

Aber bevor ich doch vielleicht wieder mit "mblen()" und "strcoll()" die Zahlen vergleiche: Was ich noch gerne fragen wollte, ist, wie man den Wert eines Bytes eines integers (oder einer anderen größere Dateneinheit) bekommt. Wenn ich das richtig verstehe, so:

Code: Alles auswählen

char byte[4];
int i;

byte[3] = i & 0xFF;
byte[2] = (i >> 8) & 0xFF;
byte[1] = (i >> 16) & 0xFF;
byte[0] = (i >> 24) & 0xFF;

Das "&" deshalb, weil 0xFF = 11111111 ist. Dann werden mit dem "&" alle Bits, die 1 sind, als 1 übernommen und alle anderen als "0", da nur 1 und 1 gleich 1 ist, aber 0 und 1 gleich 0.
Oder geht auch:

Code: Alles auswählen

char byte[4];
int i;

byte[0] = (i << 24) & 0xFF;
byte[1] = (i << 16) & 0xFF;
byte[2] = (i << 8) & 0xFF;
byte[3] = i & 0xFF;

?
i wird ja nie bleibend verändert, oder?

Danke übrigens für den Link zu Deinem Vortrag und Deinem Material. Da hast Du Dir ja richtig viel Mühe gemacht!
Also, ASCII = Charset, Unicode = Charset, aber UTF-8 = Encoding.

[Meillo]

Ein int kann vier Bytes gross sein, Er kann aber auch nur zwei Bytes gross sein, und wahrscheinlich kann er auch acht Bytes gross sein (das muesste ich aber nochmal nachlesen). Du triffst also eine Annahme, die den Code unportabel macht.

Besser waere es, ``sizeof(int)'' zu verwenden, um die Groesse zu ermitteln.

Zudem hast du Byte-Orders noch nicht bedacht, also Big Endian und Little Endian.

[RobertDebiannutzer]

Nein, nein, ich wollte das nicht genau so in meine Funktion einbauen, keine Sorge! Ich hatte mich nur mal prinzipiell dafür interessiert. Der zweite Schnipsel ist übrigens falsch (habe es einfach mal kompiliert und probiert) und müsste heißen:

Code: Alles auswählen

	byte[0] = (i >> 24) & 0xFF;
	byte[1] = (i >> 16) & 0xFF;
	byte[2] = (i >> 8) & 0xFF;
	byte[3] = i & 0xFF;

Ich werde jetzt eben doch wieder mit mblen und strcoll die Zahlen vergleichen. Du hast schon Recht - warum unnötig Inkompatibilitäten in Kauf nehmen...

[Meillo]

Aber schau dir das Byte-Order-Zeug ruhig mal an. Dann verstehst du z.B. auch, warum es UTF-16-LE und UTF-16-BE gibt, aber nur ein UTF-8.

Ich finde es gut, dass du diese ganzen Experimente machst. Nur weiter so!

[RobertDebiannutzer]

Danke. Leider muss ich spätestens zum 20.12. (also übermorgen) mit dem Experimentieren erstmal praktisch aufhören, da ich Mitte Januar Prüfungen habe (und Anfang April noch einmal...). Nennt sich Abitur oder so. (Für Leistungskurs Mathematik bin ich ja schonmal bestens gerüstet, da ich nun ja weiß, dass 1+1=1 ist... )
Aber ein Zwischenergebnis können wir ja auf jeden Fall schon einmal festhalten: Als Programmier-Anfänger ist man mit seinen Fragen hier im debianforum auf jeden Fall richtig. Danke!

[RobertDebiannutzer]

Ich muss mal für interessierte Mitleser ein kleines Update machen, auch wenn meine Funktion immer noch nicht fertig ist (ich habe bisher aber schon mindestens 10 Entwürfe angefertigt).
Denn ich glaube, dass mir kürzlich etwas Wesentliches klar geworden ist:

Für den Linux-Kernel sind Dateinamen eine Kette von Bytes, also in C ausgedrückt ein "char"-Array. Deswegen gibt es für Linux-Systeme auch nur Funktionen wie "open()" oder "fopen()", die als Dateinamen einen Pointer zu einem "char"-Array erwarten, nicht etwa einen Pointer zu einem "wchar_t"-Array.
So, aber damit ist auch klar, dass Dateinamen niemals in UTF-16 oder UTF-32 codiert sein können! Denn beide Encodings nutzen Null-Bytes, um überflüssigen Platz in den zwei-/vier-Byte-Einheiten aufzufüllen.
Ihr könnt das sehr schön an einem kleinen Experiment sehen. Man öffne vim und tippe ein "ä" in den Buffer. Anschließend speichere man es unter verschiedenen Encodings in verschiedenen Dateien, also z.B. mit:

Code: Alles auswählen

:w ++enc=utf-8 u8
:w ++enc=utf-16 u16
:w ++enc=utf-32 u32

Anschließend hat man:

Code: Alles auswählen

user@hostname:~$ ll u*
-rw-r--r-- 1 user user 4 Mar  7 10:09 u16
-rw-r--r-- 1 user user 8 Mar  7 10:09 u32
-rw-r--r-- 1 user user 3 Mar  7 10:09 u8

und:

Code: Alles auswählen

user@hostname:~$ hd u16
00000000  00 e4 00 0a                                       |....|
00000004
user@hostname:~$ hd u32
00000000  00 00 00 e4 00 00 00 0a                           |........|
00000008
user@hostname:~$ hd u8
00000000  c3 a4 0a                                          |...|
00000003

("0a" ist das newline-Zeichen)

Wichtig ist zudem:

The external encoding is byte-based and can be chosen appropriately for the environment and for the texts to be handled. A variety of different character sets can be used for this external encoding (information that will not be exhaustively presented here–instead, a description of the major groups will suffice). All of the ASCII-based character sets fulfill one requirement: they are "filesystem safe." This means that the character '/' is used in the encoding only to represent itself. Things are a bit different for character sets like EBCDIC (Extended Binary Coded Decimal Interchange Code, a character set family used by IBM), but if the operating system does not understand EBCDIC directly the parameters-to-system calls have to be converted first anyhow.

Quelle: https://www.gnu.org/software/libc/manua ... Char-Intro (aus dem glibc-Handbuch)

Das alles scheint mir u.a. zu bedeuten:
1. Die Umwandlung von char* zu wchar_t* in meiner Funktion - das habe ich u.a. auch probiert - kann ich mir total schenken.
2. Ich kann ganz normal ein "char" mit einem character-literal vergleichen, also z.B. "if (*str == '.')" oder "if (*str == '0')" oder "if (*str == '/')".

In einer früheren Version des glibc-Manual stand sogar explizit:

Because the basic ASCII characters in the range from 0 to 0177 are so important, they stand for themselves in all multibyte character codes. That is to say, a byte whose value is 0 through 0177 is always a character in itself. The characters which are more than one byte must always start with a byte in the range from 0200 through 0377.

Quelle: http://kirste.userpage.fu-berlin.de/che ... bc_18.html
(Achtung: Die Zahlen dort sind nach dem Oktalsystem angegeben.)
Warum das so klar nicht mehr im aktuellen glibc-Handbuch steht, weiß ich nicht, liegt vielleicht daran, dass man nun noch mehr Spezialfälle berücksichtigen will?

[RobertDebiannutzer]

1. Die Umwandlung von char* zu wchar_t* in meiner Funktion - das habe ich u.a. auch probiert - kann ich mir total schenken.

Ergänzung: Damit meinte ich nur: Es ist nicht zwingend notwendig. Es kann dennoch praktisch sein, wenn man ein Zeichen pro Einheit haben möchte. Ob das bei meiner Vergleichs-Funktion allerdings notwendig ist, hängt von der Herangehensweise ab.

Somit macht wchar_t wohl hauptsächlich für Programme wie Texteditoren Sinn.
Wobei - zu wchar_t sagt das glibc-Handbuch:

The ISO C90 standard, where wchar_t was introduced, does not say anything specific about the representation. It only requires that this type is capable of storing all elements of the basic character set. Therefore it would be legitimate to define wchar_t as char, which might make sense for embedded systems.

But in the GNU C Library wchar_t is always 32 bits wide and, therefore, capable of representing all UCS-4 values and, therefore, covering all of ISO 10646. Some Unix systems define wchar_t as a 16-bit type and thereby follow Unicode very strictly. This definition is perfectly fine with the standard, but it also means that to represent all characters from Unicode and ISO 10646 one has to use UTF-16 surrogate characters, which is in fact a multi-wide-character encoding. But resorting to multi-wide-character encoding contradicts the purpose of the wchar_t type.

Quelle: https://www.gnu.org/software/libc/manua ... Char-Intro

Wenn wchar_t nicht zwingend fähig ist, alle Zeichen zu enthalten, ist das natürlich keine Vereinfachung zum normalen "char"-Array, sondern eine Verschlechterung, weil man ja dennoch den überflüssig beschlagnahmten Speicherplatz hat.
Da wären dann möglicherweise so Neuigkeiten wie char32_t besser. Wobei es dazu soweit ich herausgefunden habe keine Funktionen gibt, außer welche, die multi-byte-strings zu char32_t-strings umwandeln oder umgekehrt. Ansonsten müsste man halt einen eigenen Datentyp definieren... Aber das hat dann nix mehr mit meiner compare-Funktion zu tun. Ist aber trotzdem interessant...

[RobertDebiannutzer]

Nennt sich Abitur oder so.

Successfully completed.

warum es UTF-16-LE und UTF-16-BE gibt, aber nur ein UTF-8

Hm, nach allem, was ich bisher meine verstanden zu haben, kann man das so absolut nicht sagen. Denn byte order spielt ja nur dann eine Rolle, wenn wir Einheiten verwenden, die aus mehreren Bytes bestehen (also z.B. wchar_t, int, char16_t, char32_t). Diese können wir aber im Prinzip ebenso für UTF-8 verwenden, wie für UTF-16/-32 (es würde nur wenig Sinn ergeben). Genauso könnten wir (im Prinzip!) auch UTF-16 bzw. UTF-32 in einzelnen Bytes speichern (also als char-array in C). Nur dann müsste man darauf achten, statt der str*-Funktionen die mem*-Funktionen zu verwenden, also z.B. statt strcpy() memcpy(). Und man müsste natürlich die Länge der strings separat speichern.
Vorteil der Speicherung von UTF-16/-32 als char-array wäre, dass man sich nicht auf die Anzahl der Bytes in wchar_t verlassen müsste bzw. viele Bibliotheks-Funktionen zur Auswahl hat. Da allerdings diese Form des Umgangs mit diesen Encodings sehr wenig Sinn macht, wäre imho bewiesen, dass @meillo Recht hat, wenn er meint, dass UTF-8 das einzig wahre Encoding für das Unicode-Charset ist...