C++-double/int zu Java double/int
-
ne.
andere plattform (wahrscheinlich) andere darstellung der zahlen;
auch haengt es vom compiler ab, wie die einzelnen zahlen dargestellt
werden.
in java werden alle zahlen immer gleich dargestellt, weil java
die jeweilige hardware durch die jvm abstrahiert.
-
in java werden alle zahlen immer gleich dargestellt, weil java
die jeweilige hardware durch die jvm abstrahiert.Eben. das war klar. Ich wusste nur nicht, ob das nun in C++ eventuell auch so ist.
-
verwechselt hier jmd little mit big endian?
mal ein kleines zitat aus dem netz
Unter Big- und Little-Endian versteht man die Anordnung des most significant byte.
Beispielsweise möchte man den 32-BIT hex Wert FF01DE45 in den Speicher schreiben. Adresse 00 01 02 03
Big-Endian FF 01 DE 45
Little-Endian 45 DE 01 FF
Für den westlichen Menschen ist es leichter das Big-Endian Format zu lesen, da es Zahlen genauso darstellt, wie er es liest, von links nach rechts.Big-Endian Systeme sind z.B.:
Motorola MC68000(Amiga, Atari)
SPARC CPU's (SUN)
IBM PowerPC
Little-Endian Systeme sind z.B.:Intel CPU's
VAX
DEC alphaDie Begriffe Big-Endian und Little-Endian stammen aus der Geschichte Gulliver's Reisen. Die Bevölkerung von Lilliput wurde in zwei Lager aufgeteilt. Einmal die, die ihr Ei an dem dünnen (little) Ende öffneten. Diese nannten sich Little-Endians und einmal die, die ihr Ei an dem dicken (big) Ende öffneten. Diese nannten sich Big-Endians.
und ich glaube nicht das c++ sich ums zahlenformat schert...die sprache nimmt das was sie vom system vorgesetzt bekommt...
bye
tt
[ Dieser Beitrag wurde am 03.06.2003 um 18:24 Uhr von TheTester editiert. ]
-
Ok, also was beim Integer auf jeden Fall klar ist:
C++: Von links nach recht, also 26 = 26 0 0 0
Java: Von rechts nach links, also 26 = 0 0 0 26Jetzt ist für mich eben die grosse Frage, wie Double in Java und C++ behandelt werden...
Zu einem Double in C++ hab ich folgendes herausbekommen: (MSdN)
The double type contains 64 bits: 1 for sign, 11 for the exponent, and 52 for the mantissa. Its range is +/–1.7E308 with at least 15 digits of precision.Zu einem Double in Java:
double 64 Bit IEEE 754 Fließkommazahl (sagt mir nix!)
Wobei IEEE 754 bedeutet:
1 Bit Sign
11 Bit Exponent
52 Bit MantissaWertebereich und Präzision scheinen auch übereinzustimmen!
Hab auch gerade was gelesen, dass in C++ double wohl auch der IEEE 754-Norm entsprechen!==> Scheint so als wären die bei beiden gleich !!! (wäre cool!)
Ich hab heute keine Zeit mehr, aber ich werde das morgen abend mal austesten!
Danke auch für Eure Hilfe!
Gruss, Tobias[ Dieser Beitrag wurde am 03.06.2003 um 21:34 Uhr von tobis79211 editiert. ]
-
C++: Von links nach recht, also 26 = 26 0 0 0
ist das nur so weil dein prof dir das gesagt hat? oder gibts dafür auch ein beweis...?
ich frag aus interesse leider kann ich nämlich deiner argumentation nicht folgen...vielleicht bin ich auch zu blöd für keine ahnung...aber alleine schon diese darstellung
[...]26 = 26 0 0 0 [...]
was soll das überhaupt darstellen...ja ne 26 das seh ich und was sollen die nullen da? ich meine das sieht ja noch nich mal aus wie ne speicherstelle oder sonst was...ich seh einfach nur ne 26 und 3 nullen...könnte auch 26000 sein..ich meine HÄÄÄÄÄ? und computerintern stehen sowieso nur binärzahlen 0'en und 1'en und die entweder nach big oder little endian format...deine argumentation in meinem post zur binärdarstellung war schon recht fraglich...ich bitte um korrekte aufklärung der sache :)und wenn nich von dir dann möge sich doch bitte bitte jmd anders erbarmen
und mal was anderes...warum sollte sich java oder c++ nicht an den ieee standard halten? und mal ganz davon abgesehen...ne ordinäre textdatei für die zahlenwerte war nich gut genug wa?
bye
tt
[ Dieser Beitrag wurde am 03.06.2003 um 23:07 Uhr von TheTester editiert. ]
-
Ne gibts nicht, das ist Unsinn. C++ definiert die Bytereihenfolge nicht.
Die unterliegende Maschine tut das. Intelprozessoren benutzen idR die Little Endian Ordnung, dh das niederwertigste Byte kommt zuerst. Manche andere benutzen Big Endian Ordnung. Sun-Prozessoren zum Beispiel, und darum wohl auch die Java VM. Es sind auch andere Reihenfolgen denkbar, aber unüblich.
-
Hi TheTester,
sorry wenn du es nicht verstehst!
Schreib Dir doch einfach mal eine kleine Binär-Datei, schreib einen int=26 rein und guck dir das ganze z.B. in einem Hex-Editor an...
Da "siehst" du nämlich einfach KEINE 0 und 1, sondern für jedes BYTE EINEN Wert von 0-255!
Wenn Du dazu fragen hast, mach einen neuen Thread auf, dann helf ich Dir gerne!Auf jeden Fall gibt es einfach anscheinend keinen Standard für integer!
Zumindest hab ich haufenweise Links für Float und double gefunden, aber keinen für integer!
Daher, denke ich ohne es zu wissen, kann es schon sein, dass für Integer jeder macht was er will! Oder?Gruss, Tobias
[ Dieser Beitrag wurde am 03.06.2003 um 23:27 Uhr von tobis79211 editiert. ]
-
ah so...hexwerte also..dann soll diese 26 = 26 0 0 0 darstellung von dir die hex darstellung von 26 sein?
ne aber mal im ernst...wenn das die oben die "hex" darstellung und du das auf einem little endian system laufen hast dann stimmts doch...
die zahl 26 im little endian würde 01011 lauten und im big endian format 11010, halt genau wie es in dem text steht den ich reingepostet hatte...(insofern ich dsa nicht fehlinterpretiert habe)
so und gehen wir mal davon aus das wir einen 32bit integer haben und den in 4 acht bits blöcke teilen also jeweils 1 byte dann dürfte dort nach dem LE format
deine 26 als hexwert und 0 0 0 stehen und im BE format deine 0 0 0 26 als hexwert
so und bei c++ ist das halt 26 0 0 0 weil dus auf nem was auch immer auf jedenfall nicht BE system laufen hast intel, amd oder? und c++ sich grad mal die darstellung holt die das system vorgibt und bei java isses halt anders, weil wie schon einer meiner vorgänger sagte, weil java von sun kommt und die sunrechner ein BE format benutzen und durch die vm sowieso unabhängig vom system arbeitet
so und da es mich nich wundern würde wen sun alle beide formate unterstützt habe ich mal auf java.sun.com nachgeschaut und das hier gefunden
http://java.sun.com/j2se/1.4.1/docs/api/java/nio/ByteOrder.htmlund da hast du ja richtig viel zur auswahl...zb. die native byte order...wo sich java die byte order von dem zugrunde liegenden system holt...oder du schaltest einfach komplett auf little endian um...
so und jetzt noch zum abschluss c++ ist bestimmt nicht an der byte order schuld und verantwortet das sicher nicht von selbst
sondern das system das du benutzt gibt es praktisch vor...bye
tt
[ Dieser Beitrag wurde am 04.06.2003 um 07:59 Uhr von TheTester editiert. ]
-
sehr gut recherchiert!
-
Hi,
das bedeutet doch jetzt, wenn ich da was richtig verstanden habe, dass ich, um die ByteOrder nutzen zu können, mit dem Packetjavax.imageio.streamEinlesen muss, odeR?