JAVA: short in byte[2]

[Zarathustra]

Vielleicht ist das ja einfacher als ich denke, aber...

wie zur Hölle wandelt man in Java short (ist ja 2 Byte groß) in ein byte-Array mit 2 Teilen um?

[Coda]

Vielleicht gar nicht, weil die Anordnung platformabhängig ist.

[Aqualon]

Den short mit 0xFF verunden (bitweises &), danach um 8 Bit nach rechts shiften und wieder mit 0xFF verunden.

short s = 0xA55A;
byte lo = (byte) (s & 0xFF);
byte hi = (byte) ((s >> 8) & 0xFF);

Quelle: http://forum.java.sun.com/thread.jspa?threadID=228371

Um die richtige Byte-Ordner musst dich dann selber kümmern.

Aqua

Edit: Man sollte schon um 8 bit shiften und nicht um 8 byte... ;)

[HellHorse]

byte hi = (byte) ((s >> 8) & 0xFF);
Ich hab's nicht ausprobiert, aber meine, das sollte reichen
byte hi = (byte) (s >>> 8);


Um die richtige Byte-Ordner musst dich dann selber kümmern.

Bist du sicher?

[Coda]

Ne, mit einem Shift sollte das platformunabhängig sein.

[HellHorse]

*hier stand Müll*

[zeckensack]

Den short mit 0xFF verunden (bitweises &), danach um 8 Bytes nach rechts shiften und wieder mit 0xFF verunden.

short s = 0xA55A;
byte lo = (byte) (s & 0xFF);
byte hi = (byte) ((s >> 8) & 0xFF);

Quelle: http://forum.java.sun.com/thread.jspa?threadID=228371

Um die richtige Byte-Ordner musst dich dann selber kümmern.

AquaUm die Byte-Order muss man sich damit nicht mehr kümmern. Solche Probleme haben nur Assembler-Asketen und unverbesserliche Pointer-Caster :naughty:
Das reicht schon so :)

Ääähhh. Ohhhh. Coda war schneller ;(
Deswegen einfach mal Ack@Coda =)

[Zarathustra]

Danke Jungs! :D

Aber warum nach rechts verschieben, steht denn rechts nicht das hi-byte das dabei rauskommen soll? Das muss doch nach links verschoben werden...?

[Coda]

Rechts sind die niederwertigen Bits wie beim Dezimalsystem auch, stimmt also schon.

[Zarathustra]

Hups ich Dummerchen. :biggrin:

[Aqualon]

Um die Byte-Order muss man sich damit nicht mehr kümmern. Solche Probleme haben nur Assembler-Asketen und unverbesserliche Pointer-Caster :naughty:
Das reicht schon so :)
Ich glaub ich wurde zuviel mit Assembler gefoltert in letzter Zeit ;)

Java speichert sein Zeug ja immer als Big Endian, von daher passt das schon, solange man es nur javaintern verarbeitet.

Aqua

[Coda]

Java speichert sein Zeug ja immer als Big Endian, von daher passt das schon, solange man es nur javaintern verarbeitet.Ich hoffe du meinst mit "speichern" die Festplatte.

[Aqualon]

Ich hoffe du meinst mit "speichern" die Festplatte.Wenn ich http://mindprod.com/jgloss/endian.html richtig verstanden habe, werden alle Zahlenformate von Java als Big Endian behandelt (egal ob sie jetzt im RAM liegen oder auf einer Festplatte gespeichert werden).

Aqua

[Coda]

Das hast du mit Sicherheit falsch verstanden, sonst wäre es auf Little-Endian Maschinen abnormal langsam.

[Aqualon]

This method is defined so that performance-sensitive Java code can allocate direct buffers with the same byte order as the hardware. Native code libraries are often more efficient when such buffers are used.Und was ich bisher in den Foren bei Sun gelesen habe, bestaetigt meine Einschaetzung, dass Java intern alles als Big Endian handhabt, wenn man es ihm nicht anderweitig vorschreibt.

Aqua

[Coda]

Also ein 32bit Integer wird sicher nicht bei jedem load oder store konvertiert werden bei x86, das solltest du einsehen.

Wenn etwas nach außen gespeichert wird, konvertiert Java wohl alles nach Big-Endian, das bestreite ich ja gar nicht.

[Xmas]

Für Code, der weder Pointer verwendet noch Byteströme liest, ist Endianness völlig egal. Man muss sich nur bei I/O und evtl. bei Aufruf von nativem Code Sorgen machen.