Wieso gibts kein unsigned in Java?

für list usw. zugriff mit get()

tfa

Don't hang around schrieb:

für list usw. zugriff mit get()

Ja und? Hast Du mehr als 2,4 Mrd. Einträge?

Gregor

tfa schrieb:

Ja und? Hast Du mehr als 2,4 Mrd. Einträge?

Soetwas könnte ich mir durchaus vorstellen.

Zum unsigned: Ich weiß nicht, was die offizielle Begründung dafür ist. Es gibt da aber zumindest auch Aspekte, die die JVM betreffen. Der Bytecode ermöglich nur eine sehr begrenzte Anzahl an Befehlen. Und die Anzahl der Befehle steigt mit jedem zusätzlichen Typ.

tfa schrieb:

Don't hang around schrieb:

für list usw. zugriff mit get()

Ja und? Hast Du mehr als 2,4 Mrd. Einträge?

Ne, aber man kann nicht auf negative Einträge zugreifen. Also ist kein IndexOutOfBounds in diese Richtung möglich.

Gregor

Don't hang around schrieb:

Ne, aber man kann nicht auf negative Einträge zugreifen. Also ist kein IndexOutOfBounds in diese Richtung möglich.

Es gibt Leute, die in Java Arrays folgendermaßen durchlaufen:

for(int i = array.length - 1 ; i >= 0 ; --i)

Jetzt stell Dir mal vor, das wäre ein unsigned int.

Es gibt Leute (offensichtlich nicht in Java ;)) die Arrays so durchlaufen:

my_unsigned++;
foo( my_array[ my_unsigned%16 ] );

Gregor

Tim schrieb:

Es gibt Leute (offensichtlich nicht in Java ;)) die Arrays so durchlaufen:
my_unsigned++;
foo( my_array[ my_unsigned%16 ] );

Erklär mal das %16.

Naja, typischerweise macht man es in Java heutzutage so:

for(MyObject myObject : myArray) foo(myObject);

Gregor schrieb:

Tim schrieb:
Es gibt Leute (offensichtlich nicht in Java ;)) die Arrays so durchlaufen:
my_unsigned++;
foo( my_array[ my_unsigned%16 ] );
Erklär mal das %16.

Öhmm, was genau soll ich da jetzt erklären?

Gregor schrieb:

Naja, typischerweise macht man es in Java heutzutage so:

for(MyObject myObject : myArray) foo(myObject);

Klar gibts es andere Möglichkeiten sowas zu realisieren. Ich verstehe trotzdem nicht, warum es kein unsigned gibt (war mir btw. auch neu).

Gregor

Tim schrieb:

Ich verstehe trotzdem nicht, warum es kein unsigned gibt (war mir btw. auch neu).

Ein Befehl im Bytecode ist genau ein Byte lang. Das heißt, dass es 256 unterschiedliche Befehle geben kann. So um die 200 sind davon AFAIK belegt.

Jetzt guck Dir mal an, was es da zum Beispiel für Befehle gibt:

i2b
i2c
i2d
i2f
i2l
i2s

l2d
l2f
l2i

f2d
f2i
f2l

d2f
d2i
d2l

usw.

Die da oben sind alle dazu da, um Konvertierungen zwischen 2 unterschiedlichen Typen zu machen. Darüber hinaus gibt es noch weitere typspezifische Befehle. Du kannst Dir überlegen, dass das entsprechend deutlich mehr wären, wenn es da noch ein unsigned int geben würde. ...und ein unsigned byte, ein unsigned short und ein unsigned long. Vermutlich würdest Du alleine dadurch nicht mehr mit einem Byte für die Befehle auskommen. ...jetzt muss man im Auge behalten, was man mit Java ursprünglich im Sinn hatte. Applets und so waren am Anfang stark im Gespräch. Das heißt, dass einem die Größe eines Programms zu diesem Zeitpunkt wichtig war. Das Applet musst Du schließlich erstmal runterladen und da macht ein Faktor 2 in der Größe jedes Befehls durchaus etwas aus.

Der nächste Schritt ist dann, dass man sich anguckt, was man durch ein unsigned eigentlich an Ausdrucksstärke gewinnt. Wie nötig ist das eigentlich? Ist es vielleicht sogar schlecht? Anscheinend ist es zumindest nicht sooo nötig, denn Java kommt bisher ja auch ganz gut ohne dem unsigned aus.

*Disclaimer: Diese Motivation gegen das unsigned, das ich hier versucht habe, zu skizzieren, beruht auf purer Spekulation.*

LinkeT

@Gregor

in anderen sprachen gibt es 1 und 2 bytelange befehle ... also wirds das doch auc in java geben,
wenn es dich interresiert wie das funktioniert:
00-EF 1 byte befehle
F0-FF 2 byte befehle
so kommt man locker auf 240+16*256 befehle ... also 4336 befehle und da is dann sauig viel paltz für solche unsigned befehle usw ...

zum thema unsigned gibts nich in java ... tjo hat wohl eher nachteile als vorteile ... ich mags zB bei php auch nicht das 7,8 GB = -3,.. GB sind ...

rüdiger

@Gregor
ich glaube nicht, dass das ein Problem war. Hätte man unsigned-Datentypen gewollt wäre es wohl möglich gewesen. Ich denke eher man hat sich bewusst gegen unsigned entschieden, da man so vermutete einige typische Anfänger-Fehler zu vermeiden. (Also das höhere Ziel der Java-Entwickler).

@LinkeT
ein Format mit unterschiedlich langen Bytecodes ist schrecklich. Darunter leidet ja auch x86 und x86_64. Dann lieber 2 byte pro Befehl.

pale dog

rüdiger schrieb:

ich glaube nicht, dass das ein Problem war. Hätte man unsigned-Datentypen gewollt wäre es wohl möglich gewesen. Ich denke eher man hat sich bewusst gegen unsigned entschieden, da man so vermutete einige typische Anfänger-Fehler zu vermeiden. (Also das höhere Ziel der Java-Entwickler).

das glaube ich auch.
'unsigned' bringt selten einen mehrwert, deshalb haben sie's wohl weggelassen.
btw: ich persönlich finde 'unsigned' nicht verwirrend, im gegenteil, als anfänger fand ich 'signed' variablen komisch...

rüdiger schrieb:

@LinkeT
ein Format mit unterschiedlich langen Bytecodes ist schrecklich. Darunter leidet ja auch x86 und x86_64. Dann lieber 2 byte pro Befehl.

beim x86 besser 4
am besten ist wohl, wenn der komplette befehl, einschliesslich der operanden, ein vielfaches der datenbusbreite ist...

rüdiger

pale dog schrieb:

rüdiger schrieb:

ich glaube nicht, dass das ein Problem war. Hätte man unsigned-Datentypen gewollt wäre es wohl möglich gewesen. Ich denke eher man hat sich bewusst gegen unsigned entschieden, da man so vermutete einige typische Anfänger-Fehler zu vermeiden. (Also das höhere Ziel der Java-Entwickler).

das glaube ich auch.
'unsigned' bringt selten einen mehrwert, deshalb haben sie's wohl weggelassen.
btw: ich persönlich finde 'unsigned' nicht verwirrend, im gegenteil, als anfänger fand ich 'signed' variablen komisch...

definitiv. Wobei ich nicht glaube das 'unsigned' keinen Mehrwert bringt. Es ist oft nur für Anfänger verwirrend, wenn man unsigned und signed kombiniert oder das es mehr als nur int gibt (sieht man ja im C- und C++-Forum. Selbst erfahrene Programmierer nehmen 95% der Zeit einfach int ohne nachzudenken)

rüdiger schrieb:

@LinkeT
ein Format mit unterschiedlich langen Bytecodes ist schrecklich. Darunter leidet ja auch x86 und x86_64. Dann lieber 2 byte pro Befehl.

beim x86 besser 4
am besten ist wohl, wenn der komplette befehl, einschliesslich der operanden, ein vielfaches der datenbusbreite ist...

Die Datenbusbreite ist bei Java ja egal, da der Bytecode ja eh von der Software verarbeitet wird

pale dog

rüdiger schrieb:

Wobei ich nicht glaube das 'unsigned' keinen Mehrwert bringt.

manchmal ja, aber in den meisten fällen geht's auch ohne...

rüdiger schrieb:

(sieht man ja im C- und C++-Forum. Selbst erfahrene Programmierer nehmen 95% der Zeit einfach int ohne nachzudenken)

ich kann mich an einen thread erinnern, in dem Konrad Rudolph (nach meinem eindruck nicht gerade ein C++ neuling) nach dem sinn von 'unsigned' fragte und schwer davon zu überzeugen war, dass unsigned manchmal brauchbar ist.

rüdiger schrieb:

Die Datenbusbreite ist bei Java ja egal, da der Bytecode ja eh von der Software verarbeitet wird

naja, vielleicht würde es auf X86 was bringen, wenn der bytecode 4-bytes aligned wär'?
aber dann wären wiederum die .class-files viel fetter, also keine gute idee

edit: rüdi, schalt' mal die smileys ein.
deine postings sehen sonst so seltsam aus...

rüdiger

ich kann mich an einen thread erinnern, in dem Konrad Rudolph (nach meinem eindruck nicht gerade ein C++ neuling) nach dem sinn von 'unsigned' fragte und schwer davon zu überzeugen war, dass unsigned manchmal brauchbar ist.

Ich kann mich an den Thread erinnern und dort war er am Ende ziemlich davon überzeugt, das unsigned einen Sinn hat

Ok, dann schalte ich Smilies an. Finde die nur teilweise so aufdringlich.

pale dog schrieb:

btw: ich persönlich finde 'unsigned' nicht verwirrend, im gegenteil, als anfänger fand ich 'signed' variablen komisch...

da musst du aber früh mit programmieren angefangen haben, wenn du damals noch nicht wusstest dass es auch negative zahlen gibt (die haben sogar auch einen sinn )

nep

pale dog schrieb:

rüdiger schrieb:

Wobei ich nicht glaube das 'unsigned' keinen Mehrwert bringt.

manchmal ja, aber in den meisten fällen geht's auch ohne...

Schon mal was von Bildverarbeitung gehört? Da ist es z.B. sehr wichtig, dass es auch unsigned Datentypen gibt.

Gregor

nep schrieb:

Schon mal was von Bildverarbeitung gehört? Da ist es z.B. sehr wichtig, dass es auch unsigned Datentypen gibt.

Eigentlich nicht. ...und ich mach ne Menge mit Bildern. ...ok, wäre ganz nett, wenn man ein unsigned byte hätte. Aber das war es dann auch schon. Letztendlich betrifft das dann nur eine kleine Stelle im ganzen Programm, wo man ein bischen bei der Umwandlung zwischen byte und int (oder float) trixt, um den abgespeicherten Pixelwert so zu interpretieren, wie man es gerne hätte.

Letztendlich muss man eh für viele Verarbeitungsschritte auf Datentypen ausweichen, die einen deutlich größeren Bereich als byte abdecken.

nep

Find ich nicht. Also da wo ich im Moment arbeite ist es eigentlich sehr praktisch dass es unsigned Typen gibt. Ausserdem gibt es auch viele Formate, in denen man mehrere Farbkomponeten in einem unsigned int abspeichert.
Es geht auch nicht immer nur um Bytes, gibt ja noch wesentlich mehr als nur Bittiefen von 8 Bit pro Komponente...

Ist ja nicht so, dass das unmöglich in Java wäre, aber doch sehr unpraktisch und oft auch mit Speicher/Geschwindigkeitseinbußen verbunden...

Gregor

nep schrieb:

Ist ja nicht so, dass das unmöglich in Java wäre, aber doch sehr unpraktisch und oft auch mit Speicher/Geschwindigkeitseinbußen verbunden...

Willst Du mich herausfordern? ...ein kleines Bildverarbeitungsproblem in Java zu lösen, das Du gleichzeitig in C++ löst?