unsigned byte

K

kneitzel

Gast
Etwas das sich mir bis heute nicht erschließt. Da baut man LAmbdas, Streams, Module und allen möglichen Kram ein aber ein einfaches ubyte o.ä. das man wirklich oft braucht das gibts nicht....
naja - Spätestens wenn es auch um die Arithmetik mit vorzeichenlosen Typen geht, kann es durchaus komplex werden. Etwas findet man also eine Antwort in http://www.mi.fu-berlin.de/inf/grou...avaUndvorzeichenloseDatentypen.pdf?1346661562

Und wenn man in die .Net Welt geht, dann kommt man bei vorzeichenlosen typen wie uint auch sofort in einen Bereich, der nicht CLS Compliant ist. Und wenn man in dem .Net Bereich etwas sucht, dann findet man auch diverse Ausführungen z.B. https://stackoverflow.com/questions/6301/why-is-array-length-an-int-and-not-an-uint

Das einfach nur als kleine Denkanregung ohne irgend eine Position vertreten zu wollen.
 

mrBrown

Super-Moderator
Mitarbeiter
Was dazu kommt: es würde einen Haufen mehr an Bytecode Instructions bedeuten, für einen ziemlich kleinen Gewinn. Eher wäre ein unsigned int/unsigned long sinnvoll, die nutzt man im Gegensatz zu unsigned bytes wirklich oft.

Ich hatte eigentlich noch nie den Bedarf nach explizit unsigned byte. Wenn man damit rechnen will, kann man eigentlich auch immer direkt int zum Rechnen nutzen (wird ja bei byte und short sowieso gemacht). Und wenn man nicht damit rechnet ist's eh egal.
 

Thallius

Top Contributor
Was dazu kommt: es würde einen Haufen mehr an Bytecode Instructions bedeuten, für einen ziemlich kleinen Gewinn. Eher wäre ein unsigned int/unsigned long sinnvoll, die nutzt man im Gegensatz zu unsigned bytes wirklich oft.

Ich hatte eigentlich noch nie den Bedarf nach explizit unsigned byte. Wenn man damit rechnen will, kann man eigentlich auch immer direkt int zum Rechnen nutzen (wird ja bei byte und short sowieso gemacht). Und wenn man nicht damit rechnet ist's eh egal.

Dann kannst du mal einen DICOM parser schreiben wie ich es musste. Die Files beinhalten alle verschiedenen Typen von Variablen in vorher im File festgelegter order. Also entweder Little- or Big-Endian. Was ein Spaß das in Java Variablen zu Parsen.
 

mrBrown

Super-Moderator
Mitarbeiter
Dann kannst du mal einen DICOM parser schreiben wie ich es musste. Die Files beinhalten alle verschiedenen Typen von Variablen in vorher im File festgelegter order. Also entweder Little- or Big-Endian. Was ein Spaß das in Java Variablen zu Parsen.
Und wo musst du da mit einzelnen bytes rechnen?

Dass das kein Spaß ist glaub ich sofort, nur den Zusammenhang mit signed/unsigned byte seh ich da grad nicht...
Man darf halt an ein paar Stellen nicht einfach stumpf casten
 

Thallius

Top Contributor
Und wo musst du da mit einzelnen bytes rechnen?

Dass das kein Spaß ist glaub ich sofort, nur den Zusammenhang mit signed/unsigned byte seh ich da grad nicht...

Wenn du jeden char einzeln liest und davon 4 zu einem long zusammen bauen must dann must du halt die drei bytes welche nicht das high byte darstellen (je nach Endian das erste oder letzte) als Byte behandeln
 

mihe7

Top Contributor
Ich sehe das wie Thallius. Es gibt kaum etwas schrecklicheres in Java als diesen byte-Datentyp. Wer auf Byte-Ebene arbeitet, will in der Regel gerade kein Vorzeichen oder damit rechnen, sondern schlicht Bitoperationen durchführen und zwar ohne, dass das Vorzeichen oder der automatische cast zu int dazwischenfunken. Mit byte zu arbeiten, ist in Java immer ätzend, z. B. & 0xff -> int -> cast erforderlich.
 

mrBrown

Super-Moderator
Mitarbeiter
Wenn du jeden char einzeln liest und davon 4 zu einem long zusammen bauen must dann must du halt die drei bytes welche nicht das high byte darstellen (je nach Endian das erste oder letzte) als Byte behandeln
Um Bytes als Bytes zu behandeln gibt es in Java, naja, byte.

4 Bytes in entsprechender Endian'ness zu interpretieren braucht immerhin eine ganze Zeile Code:

[CODE lang="java" highlight="3,4"]byte[] bytes = {(byte)0b10101010, (byte)0b11110000, (byte)0b00001111, (byte)0b01010101};

final int be = ByteBuffer.wrap(bytes).order(ByteOrder.BIG_ENDIAN).getInt();
final int le = ByteBuffer.wrap(bytes).order(ByteOrder.LITTLE_ENDIAN).getInt();

System.out.printf("BE: %32s%n", Integer.toBinaryString(be));
System.out.printf("LE: %32s%n", Integer.toBinaryString(le));[/CODE]

Wie gesagt: ich seh das Problem einfach nicht, vielleicht denk ich aber auch in die völlig falsche Richtung.

Hast du mal ein Beispiel, wo man damit wirklich ein Problem hat, welches man nicht einfach lösen kann?
 
Zuletzt bearbeitet:

mrBrown

Super-Moderator
Mitarbeiter
Ich sehe das wie Thallius. Es gibt kaum etwas schrecklicheres in Java als diesen byte-Datentyp. Wer auf Byte-Ebene arbeitet, will in der Regel gerade kein Vorzeichen oder damit rechnen, sondern schlicht Bitoperationen durchführen und zwar ohne, dass das Vorzeichen oder der automatische cast zu int dazwischenfunken. Mit byte zu arbeiten, ist in Java immer ätzend, z. B. & 0xff -> int -> cast erforderlich.
Störend ist dabei doch im wesentlichen nur der Cast nach int, das Vorzeichen ist auf Bit-Ebene ja egal (bis auf den Rechts-Shift)?

Die Rechenoperationen direkt für Byte anzubieten hätte halt einen Haufen mehr ans Bytecode-Instruktions bedeutet, und wenn man das gleiche dann noch für short gemacht hätte, wären alle möglichen Instruktionen ziemlich schnell aufgebraucht gewesen und die Änderungen der letzten Jahre wären nicht möglich gewesen.

Gibt es irgendwelche bit-Operationen, die nicht auch genauso gut auf int wie auf byte durchführbar sind?
 

White_Fox

Top Contributor
Ich habe mal in Java die Ausgabe einer Hardwarekommunikation auswerten müssen. (Ok, Java hab ich selber gewählt, aber eine wirkliche Wahl war das auch nicht.)

Ja, es ist schon abenteuerlich den Kram, den ein FPGA aus einer SPI-Schnittstelle rausrotzt, in Java weiterverarbeiten zu wollen. Wenn halt nur ein Byte vorgesehen ist um einen Messageframe als Userdata oder Housekeepingdata zu kennzeichnen - naja, was willste machen. Danach ein Short aus zwei Bytes um die Länge anzugeben, usw.

Aber es ging...ein Hoch auf die ByteBufferklasse, die macht es wieder relativ einfach. Das Nervigste war auch bei mir das ständige ungefragte Autogecaste. Bei der kleinsten Provokation castet Java nach int zurück, was sich bei einer Operation mit ausschließlich Bytes als Operanden nicht unbedingt erschließt.

Nachtrag:
Daß alle Datentypen in Java per Definition mit Vorzeichen sind, finde ich hingegen OK und hat mich bei meiner FPGA-Geschichte damals nicht weiter gestört. Wenn man unbedingt von 0-255 rechnen müssen können will...naja, casteste halt nach short oder int. Ist halt so. Was willste machen...und die Geräte, auf denen eine JVM läuft, sind normalerweise nicht so knapp mit Speicher alsdaß solche Optimierungen da allzuviel bringen. Und selbst wenn nicht genug Speicher da ist, macht das Javaprogramm den Kohl sicherlich auch nicht mehr fett.

Nachtrag 2:
Was mir an Java - ganz im Gegensatz zu C, wo man die Freiheit zu fast jeder Schweinerei hat - so gut gefällt, ist, daß gewisse Fehler einfach nicht mehr oder nur schwer gemacht werden können. Wieviele Unfälle sind schon passiert, weil man einen Wert >127 in ein signed Byte schreiben wollte? Ist deshalb nichtmal sogar eine Arianerakete abgeschmiert?

Nachtrag 3:
Stimmt nicht ganz, das mit der Ariane 5 war ein anderes Problem (64Bit Double in 16Bit Integer reindrücken wollen mit Operand Error Exception).
 
Zuletzt bearbeitet:

mrBrown

Super-Moderator
Mitarbeiter
die Geräte, auf denen eine JVM läuft, sind normalerweise nicht so knapp mit Speicher alsdaß solche Optimierungen da allzuviel bringen. Und selbst wenn nicht genug Speicher da ist, macht das Javaprogramm den Kohl sicherlich auch nicht mehr fett.
Solche Optimierungen würden sowieso nur 6 Byte bringen (zwei Byte-Operanden, die statt 1 dann jeweils 4 Byte brauchen), und das auch nur während der Rechenoperation, und auch nur dann, wenn der 32bit-Support emuliert werden muss.

Direkter Support für Rechenoperationen mit Bytes in der JVM dürfte deutlich mehr Speicherplatz brauchen.
 

White_Fox

Top Contributor
Ohnehin wäre direkte Byteunterstützung mit ziemlicher Wahrscheinlichkeit nur dann sinnvoll, wenn diese Unterstützung direkt an die Hardware weitergegeben werden kann. Wenn die JVM selber Byteoperationen mit "echten" Bytes durchführen würde, das hardwareseitig aber sowieso wieder in ein 32-Bit-Integer gecastet werden muß, dann ist das ja offenkundig Blödsinn.

Ich hab STM32 bisher nur aus C-Sicht programmiert und mich mit den einzelnen Registern nur soweit beschäftigt wie nötig um die Hardware zu konfigurieren, aber aus dem Bauch heraus würde ich mal sagen daß 16-Bit die minimale Registerbreite ist. Jedes Konfigurationsregister ist da wenigstens 16-Bit breit, öfter auch 32 (ist ja eine 32-Bit-Architektur), auch wenn da manchmal nur zwei oder gar ein Bit belegt ist.

Daher könnte ich mir sehr gut vorstellen, daß moderne CPUs, die ja schon seit Jahren 64-Bit-Operationen unterstützen, allerhöchstens noch 32-Bit-Operationen nativ unterstützen - alles darunter wird gnadenlos nach 32-Bit-Datentyp gecastet.
Eigentlich würde ich mich sehr wundern, wenn mein AMD A7, auf dem ich gerade unterwegs bin, tatsächlich noch hardwareseitig 16-Bit-Operationen durchführt. Das würde nähmlich dynamische Ressourcenverwaltung - und damit den Bau und Funktion von Betriebsystemen - erheblich erschweren und verlangsamen. Von acht Bit fange ich da gar nicht erst an.
 

httpdigest

Top Contributor
Aktuelle 64-bit x86 CPUs zumindest unterstützen nach wie vor 8-bit, 16-bit, 32-bit und 64-bit Operationen. Allerdings spielt es keine Rolle, welche davon man wählt, da zumindest für integer-arithmetik und bitweise Operationen alle nur 1 Clockzyklus brauchen. Die ALU in solchen CPUs macht halt einfach nur 64-bit Operationen und maskiert bei kleineren Registerbreiten dann einfach die höheren Bits weg.
Es ist wirklich absolut irrelevant und verbraucht auch nicht mehr "Speicher", wenn man byte, short, int oder long als Methodenoperanden verwendet (vorausgesetzt, man verwendet eine moderne JVM und einen modernen Prozessor).
Zum Beispiel kann man auch ein 64-bit Register nicht "gleichzeitig" für zwei 32-bit Operationen verwenden, da zumindest bei x86 alle Operationen immer auf den niedrigwertigen "Prefixen" eines Registers definiert sind, z.B. ADD: https://c9x.me/x86/html/file_module_x86_id_5.html
Hier kann man die niedrigen 8-bit, 16-bit oder 32-bit eines Registers für Addition verwenden, aber eben keinen anderen "Teil" davon.
 
Zuletzt bearbeitet:

mihe7

Top Contributor
Was mir an Java - ganz im Gegensatz zu C, wo man die Freiheit zu fast jeder Schweinerei hat - so gut gefällt, ist, daß gewisse Fehler einfach nicht mehr oder nur schwer gemacht werden können. Wieviele Unfälle sind schon passiert, weil man einen Wert >127 in ein signed Byte schreiben wollte?
Da sehe ich in Java die größere Gefahr, weil sich byte und int durch den automatischen Cast (scheinbar) völlig anders verhalten.

Schauen wir uns mal an, wie int funktioniert:
Java:
int v = 0xff000000;
int out = v >> 1;
System.out.println(out);
OK, wer hier den Wert 0x7f800000 erwartet, der wird schon einmal vom signed shift right enttäuscht: 0xff800000 kommt hier raus.

Aber, man wird ja schlauer, also nochmal:
Java:
int v = 0xff000000;
int out = v >>> 1;
System.out.println(out);
Wunderbar: Wert halbiert.

So, jetzt machen wir das mal mit byte:
Java:
byte v = (byte)0xff;
byte out = (byte)(v >> 1);
System.out.println(out);
Wie erwartet: 0xff. Jetzt mal den richtigen shift operator verwenden:
Java:
byte v = (byte)0xff;
byte out = (byte)(v >>> 1);
System.out.println(out);
-1...

Das v wird erstmal zu einem int erweitert, aus -1 wird -1, d. h. alle Bits gesetzt, da ist es dann natürlich egal, welchen Shift-Operator man verwendet. Um das zu verhindern, muss man das byte zuvor in einen vorzeichenlosen Wert wandeln:
Java:
byte v = (byte)0xff;
byte out = (byte)((v & 0xff) >>> 1);
System.out.println(out);

Da gibt es in Java doch ein wenig mehr Fallstricke als in C:
C:
    unsigned char value = 0xff;
    printf("%d\n", value >> 1);
 

mrBrown

Super-Moderator
Mitarbeiter
Zuletzt bearbeitet:

mihe7

Top Contributor
Das ist schon richtig, nur macht das jetzt für das Beispiel auch keinen Unterschied: byte in Java ist und bleibt grausam :)
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
kodela Datentypen byte als unsigned interpretieren Allgemeine Java-Themen 23
T "unsigned" byte[] -> BigInteger Allgemeine Java-Themen 2
RalleYTN Unsigned int in signed int umwandeln Allgemeine Java-Themen 8
Q Datentypen Short aus Bytes - Signed -> Unsigned? Allgemeine Java-Themen 9
S String zu binary und zurück - Problem mit unsigned/signed bytes Allgemeine Java-Themen 2
R AWT signed/unsigned Allgemeine Java-Themen 3
S Unsigned Ganzzahlen Allgemeine Java-Themen 5
O Konvertierung Signed-Unsigned und HEX, DEC, BIN Allgemeine Java-Themen 2
G signed/unsigned Allgemeine Java-Themen 9
E unsigned int Allgemeine Java-Themen 24
LucasGlockner Effizienter byte-Zugriff auf ein long[]-Array Allgemeine Java-Themen 8
Encera Größe eines Objektes in Byte berechnen Allgemeine Java-Themen 2
M Optimierung einer Methode (byte-Geraffel) Allgemeine Java-Themen 2
Noahscript Aus einem byte Array Steuerungszeichen und Code bekommen und ersetzen Allgemeine Java-Themen 3
N Byte Array in Java "dekomprimieren" Allgemeine Java-Themen 3
W String -> byte[] -> String - Sieht jemand was ich nicht sehe? Allgemeine Java-Themen 10
TheWhiteShadow 2D-Grafik GIF Library mit byte output Allgemeine Java-Themen 10
K Data Konverter - Probleme mit Byte[] Kodierung Allgemeine Java-Themen 3
kodela Byte Order Mark (BOM) bei readLine() ignorieren Allgemeine Java-Themen 5
A Byte zu String Allgemeine Java-Themen 4
RalleYTN Datentypen Unsignierter Byte zum signierten Byte Allgemeine Java-Themen 2
X Datentypen Byte geht nicht höher als 126 auch nicht mit casten? Allgemeine Java-Themen 22
R Byte Array Zeichensuche Allgemeine Java-Themen 6
M Null byte in verschiedenen charsets Allgemeine Java-Themen 2
S Byte Array welches in Laufzeit aufgelöst wird // Objekt Array Allgemeine Java-Themen 3
O Byte-Array zu String Allgemeine Java-Themen 7
D Decodierung von Mp3-byte[] Allgemeine Java-Themen 4
A ByteBuffer.get(byte[] dst,int offset,int length) Allgemeine Java-Themen 2
A RandomAccessFile.read(byte[] b) Allgemeine Java-Themen 9
P Datentypen Warum überhaupt Byte ? Allgemeine Java-Themen 12
P Datentypen String-Daten zu Byte-Zahlen konvertieren - Komme nicht weiter nach vielem versuchen :-/ Allgemeine Java-Themen 7
E Byte zu String & umgekehrt Allgemeine Java-Themen 3
B BufferedWriter in InputStream oder Zeichen-Stream in Byte-Stream Allgemeine Java-Themen 5
M Chart per byte[] in JSP anzeigen Allgemeine Java-Themen 4
E int in byte Allgemeine Java-Themen 6
R ArrayList byte[] abspeichern Allgemeine Java-Themen 4
S byte [] in string und zurück konvertieren Allgemeine Java-Themen 2
G byte ? : Allgemeine Java-Themen 7
E Byte-Array to String: Zeichenkaputt Allgemeine Java-Themen 11
R In einem Byte-Array nach einer gewissen Zahlenfolge suchen Allgemeine Java-Themen 7
hdi Speicherbelegung byte, short, int Allgemeine Java-Themen 8
J byte - hex - byte.. casten Allgemeine Java-Themen 8
R byte[] to String Konvertieren Allgemeine Java-Themen 14
A Input/Output Buffered Image zu Byte Array und zurück konvertieren Allgemeine Java-Themen 4
M byte array splitten Allgemeine Java-Themen 3
J Hex-String zu byte transformieren Allgemeine Java-Themen 7
T Zu doof für byte-Umrechnung ... Allgemeine Java-Themen 3
W CRC32 aus byte array Allgemeine Java-Themen 5
F byte[] aus einem BufferedImage Allgemeine Java-Themen 3
L byte -> byte[1] -> byte Allgemeine Java-Themen 2
P Einzelne Bits in einem Byte-Array setzen Allgemeine Java-Themen 2
Kr0e Synchronisieren: boolean,byte,char ? Allgemeine Java-Themen 2
S Überprüfung/Parsen eines Byte-Arrays Allgemeine Java-Themen 9
Semox Byte-Manipulation eines Bildes Allgemeine Java-Themen 7
Meldanor For-Schleifen - byte statt int? Allgemeine Java-Themen 11
C int zu byte cast - verständnis Allgemeine Java-Themen 3
R int to byte[] Array Allgemeine Java-Themen 4
MQue byte[] Array to Integer Allgemeine Java-Themen 4
MQue Byte to Int convertieren Allgemeine Java-Themen 2
R Double Werte aus byte[] auslesen Allgemeine Java-Themen 5
W Verwendung von byte Allgemeine Java-Themen 9
G zu lange Byte code dateien Allgemeine Java-Themen 6
G String in byte- Array Allgemeine Java-Themen 3
E Byte [] nach hex, dann nach dec Allgemeine Java-Themen 2
A Performance: byte[] in byte[][][] konvertieren Allgemeine Java-Themen 2
G 2 x byte zusammenkopieren Allgemeine Java-Themen 7
G byte nach int Allgemeine Java-Themen 3
foobar Object to byte[] ohne Serializable Allgemeine Java-Themen 6
data89 Die Größe eines Strings in Byte berechnen? Allgemeine Java-Themen 12
G Byte- List mit einem Iterator durchlaufen Allgemeine Java-Themen 5
W Konflikt byte->int, in.read->arraycopy Allgemeine Java-Themen 7
F byte in hex-String oder: Wer hat in Mathe aufgepasst Allgemeine Java-Themen 3
T Socket Server Anwendung - Empfang eines Byte-Arrays Allgemeine Java-Themen 7
J NumberFormatException bei String->byte[] Allgemeine Java-Themen 12
ARadauer Blob aus byte Array erstellen? Allgemeine Java-Themen 3
T Object -> byte[] Allgemeine Java-Themen 5
G Byte[] zeichenweise lesen Allgemeine Java-Themen 4
G byte[] mit Strings füllen Allgemeine Java-Themen 2
B int -> byte Allgemeine Java-Themen 2
G file --> byte[] Allgemeine Java-Themen 7
E Problem beim Dateien kodieren ("Byte = Byte +1") Allgemeine Java-Themen 3
I String -> byte[] -> String Allgemeine Java-Themen 2
D byte nach integer? Allgemeine Java-Themen 4
MQue int in byte Allgemeine Java-Themen 18
G Maximalgröße von byte[] buffer Allgemeine Java-Themen 7
E String -> byte[] Allgemeine Java-Themen 6
C Byte[] to String Allgemeine Java-Themen 7
D datei in byte[]-array schreiben Allgemeine Java-Themen 6
D byte[] problem Allgemeine Java-Themen 3
MQue ArrayList in ein byte- Array Allgemeine Java-Themen 7
B ein spezielles Byte-Array sortieren Allgemeine Java-Themen 11
T OutputStream - Event bei Byte-Fluss Allgemeine Java-Themen 5
J byte-Array in Hashmap speichern? Allgemeine Java-Themen 3
S Problem beim Einlesen von byte-werten aus datei Allgemeine Java-Themen 2
J byte-Array als String übers http schicken Allgemeine Java-Themen 8
F List<String> zu byte[] Allgemeine Java-Themen 7
L byte vs. int Allgemeine Java-Themen 6
G Umwandlung Byte in Integer Allgemeine Java-Themen 12
N Byte-Code entschlüsseln (Bitmasks?) Allgemeine Java-Themen 3
R byte - string? Allgemeine Java-Themen 10

Ähnliche Java Themen

Neue Themen


Oben