Datentypen Warum überhaupt Byte ?

[phip1611]

Wie ich hier erfahren konnte wird intern bei Berechnungen int genutzt. --> interne Konvertierung von Java nötig

Warum sollte man dann überhaupt noch byte benutzen anstatt direkt int? Dadurch macht man dem System letztenendes doch nur noch mehr Arbeit. Oder?

Danke im voraus!

 

[tröööt]

der sinn hinter den verschiedenen datentypen sind deren wertebereiche ... gleich wie es java intern verarbeitet ...

 

[phip1611]

Das heißt also ich verwende int, habe einen größeren Wertebereich und gleichzeitig hat die VM weniger Arbeit?

 

[DrZoidberg]

Wegen des Speicherbedarfs. Vor allem bei Arrays.

 

[Guybrush Threepwood]

byte wird aber tatsächlich ziemlich selten genutzt, meist nur beim Ablegen der Daten in einer Datenbank, wenn überhaupt.

 

[Spacerat]

byte wird aber tatsächlich ziemlich selten genutzt, meist nur beim Ablegen der Daten in einer Datenbank, wenn überhaupt.

Was verstehst du unter Datenbank? Hoffentlich alles, womit Daten persistent gemacht werden können, z.B. auch Dateien. Für diese und andere Streams sind Bytes bzw. Bytearrays nämlich unumgänglich, auch wenn man es zunächst gar nicht mitbekommt, weil man ObjectStreams usw. verwendet. Wäre ja was, wenn man da für jedes einzelne Byte ein separates Int verwenden müsste. In dieser Hinsicht machen dann auch alle anderen niederen Datentypen wie Boolean (verschwendet gleich ganze 31 Bits), Short und Char wieder Sinn, nämlich wenn man Wertebereiche ohne ständige Bitverknüpfungen eingrenzen will bzw. muss.

 

[piu58]

Dieses (leicht lösbare) Arithmetikproblem scheint gegen Byte zu sprechen. In älteren Programmiersprachen herrscht hingegen der Ganzzahlwahnsinn. In C gibt es sechs Typen von Ganzzahlen, welche jeder Compiler anders interpretieren darf. Sie dürfen sogar alle gleich sein. Wenn man da so etwas wie Byte braucht, muss man auf char ausweichen, was eigentlich kein Zahlentyp ist.
Die Festlegungen von Java sind schon ganz vernünftig. Alles beruht auf einem Ganzzahltyp genügender Größe. Als Programmierer muss man sich viel weniger Gedanken machen und kann sich stärker auf die eigentliche Aufgabe konzentrieren. Wenn man mit byte arbeiten muss, kommte man um eine kleine eigen Bytearithmetik allerdings nicht herum, welche sich um die Überläufe kümmert.

 

[SlaterB]

Wäre ja was, wenn man da für jedes einzelne Byte ein separates Int verwenden müsste.

was wäre das denn bei Dateien? Stream-read()-Methoden liefern schon jetzt int,

hätte was auch mit int[] zu arbeiten, String.getInts() statt getBytes(), ach ja, Probleme gibts sowieso immer

 

[TheDarkRose]

In C gibt es sechs Typen von Ganzzahlen, welche jeder Compiler anders interpretieren darf. Sie dürfen sogar alle gleich sein. Wenn man da so etwas wie Byte braucht, muss man auf char ausweichen, was eigentlich kein Zahlentyp ist.

Ne, da gibts dann structs, z.b uint8, int16, etc. die einen die Länge und Typ garantieren

 

[piu58]

> uint8, int16

Die sind aber nicht standardisiert.

 

[javapower]

Die Regel ist für mich simple: Wenn es keinen zwingenden Grund gibt, für eine Ganzzahl nur 8 bit zu benutzen, dann arbeite mit ints! Analoges gilt für short!

 

[TheDarkRose]

[OT]

> uint8_t, int16_t

Die sind aber nicht standardisiert.

Jein, beim gcc aber quasi-Standard. Somit habe ich auf jedem Zielsystem meine garantierte Bitbreite, was ich benötige. Gut Qt bringt seine eigenen Typedefs mit ^^
Aber eben meist nur bei Datenströmen (UART, ...) nötig. Ansonsten sollte man wie in Java mit int arbeiten um die natürliche Bitbreite des Prozessors zu nutzen [/OT]

Die Regel ist für mich simple: Wenn es keinen zwingenden Grund gibt, für eine Ganzzahl nur 8 bit zu benutzen, dann arbeite mit ints! Analoges gilt für short!

Würde ich auch so unterschreiben. Das Argument mit dem zuviel verbrauchten Speicher wegen der Größe der ints, ist bei heutigen System IMHO irrelevant geworden.

 

[Spacerat]

was wäre das denn bei Dateien? Stream-read()-Methoden liefern schon jetzt int,

hätte was auch mit int[] zu arbeiten, String.getInts() statt getBytes(), ach ja, Probleme gibts sowieso immer

Ja, zugegeben, das tun sie. Aber erstens geben sie entweder nur die Anzahl der gelesenen Bytes oder ein gecastetes Byte aus dem Inhalt des Byte-Puffers zurück . Wäre dieser Puffer ein Int-Array, würden Speicherhersteller nur mehr Umsatz machen. Programmtechnischen Nutzen (z.B. Geschwindigkeit) hätte man jedoch keinen.
Und so irrelevant ist's in Sachen Arrays und sonstigen Puffern mit der Länge des Datentyps nun auch nicht. Ihr würdet euch wundern, wenn eine 8MB-Datei plötzlich 32MB Speicher braucht. Und wo wir schon bei Verschwendung sind...
Die Klasse BitSet wäre dann wohl auch überflüssig? Hidden evils of Java's boolean array (boolean[]) - Engineering Chronon
Also zumindest würde ich überall dort Standardtypen verwenden, wo es zunächst nicht auf die Bitsize ankommt. In Java und anderen Programmierspachen sind vorzeichenbehaftete 4-Byte-Ganzzahlen dafür ein bewährter Kompromiss.