Jabber Geschrieben 11. November 2003 Geschrieben 11. November 2003 Hallo zusammen, ich habe ein Problem mit der folgenden Aufgabe. Wir sollten in der Schule schreiben was Zahl ausgibt. Ich weiss das 2585 das Ergebniss ist. Aber ich kann den Weg nicht nachvollziehen. Unser Lehrer hatte nur noch 25+10*256 an die Tafel geschrieben und war verschwunden. Vielleicht kann mir jemand mal den Weg erklären wie man auf dieses Ergebniss kommt. Thx unsigned char z1=10, z2=25; unsigned char*p; short Zahl=0; p=(unsigned char*) &Zahl; *p=z2; p++; *p=z1; cout << Zahl; Zitieren
nic_power Geschrieben 11. November 2003 Geschrieben 11. November 2003 Hallo, Der Code ist mehr als riskant! z1 und z2 müssen nicht notwendigerweise hintereinander im Speicher liegen!! Zum einen greifst Du auf nicht allokierten Speicher zu und zum anderen ist das Speicherlayout maschinen-abhängig. Ein HP liefert beispielsweise ein ganz anderes Ergebnis!! Kein gutes Beispiel, da der Code fehlerhaft ist. Nic Zitieren
Jabber Geschrieben 11. November 2003 Autor Geschrieben 11. November 2003 Das mag gut sein das das ein schlechtes Beispiel ist! Hab die Aufgabe aber genau so in schriftlicher Form erhalten und sollte dann aus dem Quelltext erkennen können das 2585 als Ergebniss rauskommt. Wie zum Geier ist der darauf gekommen ???? Das ganze war ein Test und ich kann mich erinnern das aus der ganzen Klasse das nur einer hatte. Hmm.... :confused: Zitieren
nic_power Geschrieben 11. November 2003 Geschrieben 11. November 2003 Hallo, Das Ergebnis Deines Lehrers leider ist falsch. 10 und 25 liegen hintereinander im Speicher, der Zeiger zeigt auf die 25 (das low-order Byte einer 16 Bit-Zahl). Wird der Zeiger um eine Stelle verschoben, so zeigt er auf auf den Anfang der 16 Bit Zahl. Das Highorder-Byte dieser 16 Bit Zahl ist 10, folglich berechnet sich die 16-Bit Zahl als 10*256+25=2585. Problem ist allerdings, dass es Maschinen mit unterschiedlicher Byte-Order gibt (er geht von einer Intel-Archtektur aus). Bei umgekehrter Byte-Order wird 25*256+10=6410 berechnet (da das Low-Oder und High-Order Byte vertauscht sind). Der zweite Fehler ist die Tatsache, dass der Pointer erhöht wird, jedoch auf kein Array zeigt. Aus dem Grund kann man bei dieser Pointer-Operation auch irgendwo im Nirwana landen (obwohl dies unwahrscheinlich ist, da z1 und z2 in der Regel in aufeinanderfolgenden Speicherstellen abgespeichert werden). Nic Zitieren
M.A.Knapp Geschrieben 12. November 2003 Geschrieben 12. November 2003 unsigned char z1=10, z2=25; unsigned char*p; short Zahl=0; p=(unsigned char*) &Zahl; *p=z2; p++; *p=z1; cout << Zahl; Der Code ist zulässig und wird immer funktionieren, wenn ein short doppelt so groß ist wie ein char. (Im unteren Text gehe ich davon aus: sizeof(char) = 1, sizeof(short) = 2) Mit *p=z2; p++; *p=z1; werden die untern 8bit, dann die oberen 8 bit gesetzt. Auf einem x86 System steht das "least significant byte" (a.k.a Little-Endian) einer Integer-Variable immer an der niedrigsten Speicheradresse, daher ist das Ergebnis 256*25+10 = 6410. Hingegen auf Big-Endian (z.b: PowerPC) Systemen steht das "least significant byte" an der höchsten Speicheradresse und das Ergbnis wäre daher: 256*10+25 = 2825 Die Angabe ist ansich nicht vollständig. Weiters ist rate ich davon dringend ab, Konstrukte solcher Art in irgendwelchen Programmen zu verwenden, da sie nicht plattformunabhängig sind. Nur in seltenen Fällen, z.b. Hardware-Programmierung sind solche Methoden zulässig. MfG, Michael Zitieren
nic_power Geschrieben 12. November 2003 Geschrieben 12. November 2003 Hallo, stimmt, den cast hatte ich übersehen. Zumindest die Pointer-Arithmetik ist damit zulässig. Allerdings hast Du die Ergebnisse vertauscht. Eine Little Endian Maschine liefert 2825, eine Big-Endian Maschine 6410 (siehe auch oben). Eine Intel (ia32)-Architektur ist Little Endian und liefert daher 2825. Das kannst Du leicht überprüfen, in dem Du den Code einfach mal übersetzt und ausführst. Bei Big Endian Architekturen steht das LSB am Ende bzw. das MSB am Anfang eines Wortes ("Big End First"). Das ist übrigens auch der Grund dafür, warum man für Socket-Kommunikationen grundsätzliche die Funktionen htons/ntohs bzw. htonl/ntonl ("Host-To-Network-Byteorder"/"Network-To-Host-Byteorder" für short und long) verwenden muss. Nic Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.