Frage zu Datentypgrößen
-
Der Cast geschieht sowieso automatisch, mit dem Extra-Cast zeigt man halt dass man einen schlechten C-Lehrer hatte.
-
Ich denke, dass mein eigentliches Problem, im zweiten Parameter von mysql_real_query() liegt. Der Code für das 'Ü', in der Codepage cp850, die auf meinem XP Anwendung findet, lautet 0x9A (154). Die kann ich ja nicht mit dem Wertebereich von char darstellen.
-
Doch, das geht. Ox9A kann entweder negativ sein, falls char, signed ist, bzw. positiv, falls char unsigned ist.
char, signed char und unsigned char sind verschiedene Typen, da char entweder signed oder unsigned sein kann.
-
Super - funktioniert tatsächlich. Habe das mit dem Code 0x9A zwar schon einmal ausprobiert, aber irgendwas habe ich da wohl verkehrt gemacht. Ich danke dir für die Lösung.
Allerdings verstehe ich noch nicht so ganz, wie das abläuft. Wenn ich die Zuweisung pAscii[30] = (char) 0x9A; definiere, dann enthält diese Adresse den Wert 102, statt, wie ich gemeint habe, 154.
Genauso wenig verstehe ich, warum man bei signed char einen Wertebereich von -128 bis 127 hat. Wenn doch das höchste Bit eines Byte für das Vorzeichen gebraucht wird, dann hat man doch auf jeder Seite (+ und -) 7 Bits, um einen Wert darzustellen - also 2↑7 - 1. Somit komme ich auf 127 auf beiden Seiten.
-
_Bongo schrieb:
Genauso wenig verstehe ich, warum man bei signed char einen Wertebereich von -128 bis 127 hat. Wenn doch das höchste Bit eines Byte für das Vorzeichen gebraucht wird, dann hat man doch auf jeder Seite (+ und -) 7 Bits, um einen Wert darzustellen - also 2↑7 - 1. Somit komme ich auf 127 auf beiden Seiten.
Das wäre das Einerkomplement. Da hast du dann aber zweimal die Null: +0 und -0.
Aber so rechnen die wenigsten Prozessoren.Heute wird meist das Zweierkomplement benutzt.
^Wer kennt Lagerfeuergexhichten mit Einerkomplement?^
-
_Bongo schrieb:
Allerdings verstehe ich noch nicht so ganz, wie das abläuft. Wenn ich die Zuweisung pAscii[30] = (char) 0x9A; definiere, dann enthält diese Adresse den Wert 102, statt, wie ich gemeint habe, 154.
Wie stellst du das fest?
154 und -102 (beachte das Vorzeichen) haben dassselbe Bitmuster (bei Zweierkomplement und 8-Bit)
-
DirkB schrieb:
Das wäre das Einerkomplement. Da hast du dann aber zweimal die Null: +0 und -0. Aber so rechnen die wenigsten Prozessoren.
D.h., statt -0 zu verwenden, wird die negative Seite, um einen Wert erweitert?
DirkB schrieb:
Wie stellst du das fest? 154 und -102 (beachte das Vorzeichen) haben dassselbe Bitmuster (bei Zweierkomplement und 8-Bit)
Habe eine Kontrollvariable definiert und über den Debugger verfolgt (hast Recht mit -102. Hatte mich vertan).
Wenn ich das Komplement zu 154 (von Hand) bilde, dann komme ich aber auf 101. Wo vergesse ich denn da wieder ein Bit?
-
_Bongo schrieb:
Wenn ich das Komplement zu 154 (von Hand) bilde, dann komme ich aber auf 101.
Das wäre wieder das Einerkomplement.
-
JWolfFan schrieb:
Der Cast geschieht sowieso automatisch, mit dem Extra-Cast zeigt man halt dass man einen schlechten C-Lehrer hatte.
Wenn der Cast sowieso automatisch geschieht, dann frage ich mich, warum überhaupt casten - ausgenommen die Antwort "weil ansonsten der Compiler meckert". Das hört sich so an, als ob der Compiler sowieso implizit castet - was er ja nicht tut. Oder bedeutet kein Cast einfach nur, dass void* dann eben ein Zeiger auf ein Byte (char) ist?
-
_Bongo schrieb:
JWolfFan schrieb:
Der Cast geschieht sowieso automatisch, mit dem Extra-Cast zeigt man halt dass man einen schlechten C-Lehrer hatte.
Wenn der Cast sowieso automatisch geschieht, dann frage ich mich, warum überhaupt casten - ausgenommen die Antwort "weil ansonsten der Compiler meckert". Das hört sich so an, als ob der Compiler sowieso implizit castet - was er ja nicht tut. Oder bedeutet kein Cast einfach nur, dass void* dann eben ein Zeiger auf ein Byte (char) ist?
Der (C-) Compiler meckert nicht, wenn man denn Cast weglässt. Das funktioniert automatisch. Der Cast ist schlicht und ergreifend überflüssig.