Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Aufgabe 2 - wsort
Hallo zusammen,
ich habe gerade Aufgabe 2 (wsort) implementiert und mal meine Sortierung mit der des vorgegebenen wsort verglichen, dabei ist mir Folgendes aufgefallen:
Sortiert mit vorgegebener wsort:
Sortiert mit meiner Implementierung:
In der ASCII-Tabelle hat ein "" den Dezimal-Wert 92 und ein „e“ den Dezimal-Wert 101.
Wenn man die Woerter also zeichenweise nach der ASCII-Tabelle sortiert sollte doch „attach\82“ vor „attache“ kommen, oder?
Selbst wenn ich „\82“ als den Dezimalwert eines ASCII-Zeichens interpretiere waere das „R“ und muesste immernoch vor dem "" kommen!
Meine an qsort uebergebene Vergleichsmethode vergleicht die beiden char-Arrays einfach zeichenweise und liefert daher "" < „e“, weshalb „attach\82“ vor „attache“ kommt…
Warum sortiert die vorgegebene wsort-Implementierung das anders? Sollen wir die Stings nicht zeichenweise vergleichen (anhand des ASCII-Wertes) ?
Bzw. falls die vorgegebene Sortierung korrekt ist: warum wird das so sortiert und wie implementiert man dann den String-Vergleich richtig?
[m]\82[/m] ist die Darstellung deines Editors für das Zeichen mit dem Wert 0x82 (hexadezimal nicht dezimal) und daher ist es größer als jeder Buchstabe in ASCII und sollte daher ganz nach hinten sortiert werden.
Das ist allerdings komisch. Bei einem Vergleich sollte [m]0x82[/m] größer sein als [m]‚e‘[/m].
Eine Funktion zum Vergleichen von Strings gibt es schon: [m]strcmp(3)[/m]. Die ist übrigens auch auf dem Aufgabenblatt angegeben.
Ahh, ok das erklaert einiges… mein Problem war, dass ‘\82’ nicht als ein Zeichen, sondern als "",“8”,“2” eingelesen wurde, also 3 Zeichen.
Dann wurden die ASCII-Codes von "" und “e” verglichen.
0x82 hatte ich gar nicht in Betracht gezogen weil die ASCII-Tabelle schon vorher endet und daher 82 als Dezimal-Wert interpretiert, der waere “D” und kaeme vor “e”…
Dass 0x82 nach "" kommt ist wieder klar 
Nein, das glaube ich nicht. Ich denke, dass dein Problem ehr daher rührt, dass du zwei [m]char[/m]s mit dem [m]<[/m]-Operator verglichen hast. Da [m]char[/m]s standardmäßig vorzeichenbehaftet sind, wird jedes Zeichen dessen Wert größer als 127 ist als negative Zahl beim Vergleich interpretiert und ist damit kleiner. Also besser [m]unsigned char[/m]s verwenden.
Tatsächlich, wenn man unsiged char verwendet funktioniert es einwandfrei:
Klar, denn 0x82 hat dezimal den Wert 133 und signed char hat einen Maximalwert von 128 (2^7), d.h. (char) 0x82 wird als negative Zahl interpretiert (Overflow). Die ist natürlich kleiner als ‘e’ (0x65 bzw. 101)…
Jetzt funktioniert der Code einwandfrei, danke 