4. Wieso gibts kein unsigned in Java?

Wieso gibts kein unsigned in Java?

  • ?

    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).

    0
  • G
    Mod

    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.*

    0
  • L

    @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 ...

    0
  • R

    @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.

    0
  • P

    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...
    🙂

    0
  • R

    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 🙂

    0
  • P

    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...

    0
  • R

    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.

    0
  • ?

    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 👍 ) 😮 😮

    0
  • N

    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.

    0
  • G
    Mod

    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.

    0
  • N

    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...

    0
  • G
    Mod

    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? 😉

    0
  • N

    Ich hab eh den längeren 😛 😉

    Nein mal im Ernst. Ich denke dass wir sowieso etwas aneinander vorbeireden.
    Wir beschäftigen uns z.B. mit Formaten wie DPX oder DVS, die man so normalerweise eh nicht benutzt. Geht also weniger um so "klassische" Dinge wie z.B. Gaussfilter oder sowas. Und da ist es schon sehr praktisch die ganzen unsigned-Typen zu haben.

    0
  • P

    nep schrieb:

    Und da ist es schon sehr praktisch die ganzen unsigned-Typen zu haben.

    wieso?
    signed typen kann man auch prima shiften und mit AND/OR/XOR bearbeiten.
    🙂

    0
  • N

    Merkst du was?

    0
  • ?

    Macht das nen unterschied? Ich dachte and or und xor sind bitoperationen, bei denen nicht zwischen signed und unsigned unterschieden wird.

    0
  • G
    Mod

    nep schrieb:

    Ich hab eh den längeren 😛 😉

    Nein mal im Ernst. Ich denke dass wir sowieso etwas aneinander vorbeireden.
    Wir beschäftigen uns z.B. mit Formaten wie DPX oder DVS, die man so normalerweise eh nicht benutzt.

    Die Speicherung in bestimmten Formaten sehe ich durchaus auch als einen Bereich an, in dem unsigned Typen sinnvoll sind. Aber das war es dann schon fast innerhalb der Bildverarbeitung. ...insofern ist das nur am Rande interessant.

    BTW: Hast Du es mal ohne unsigned Typen probiert? Macht das da wirklich so einen großen Unterschied?

    BTW2: wikipedia spuckt mir bezüglich DPX etwas mit einem 10 Bit Format aus. Da passen die unsigned Typen wohl auch nicht so perfekt. Wenn Du da keinen 10-Bit Datentyp zur Verfügung hast, dann brauchst Du eh 2 Byte, um das zu verarbeiten. Da spielt es keine Rolle, ob das oberste Bit jetzt für ein Vorzeichen genutzt wird.

    0
  • N

    Bei DPX gibt es viele Bittiefen, wir benutzen maximal 16 Bit.

    Ich sag ja auch nicht, dass es nicht auch mit signed-Typen geht, es ist nur einfacher wenn man gleich unsigned-Typen hat.

    0
  • G
    Mod

    nep schrieb:

    Bei DPX gibt es viele Bittiefen, wir benutzen maximal 16 Bit.

    Umso eher nutzt man dann doch zu Verarbeitungszwecken ganz generell einen Pixeltyp, der alles einfach erschlägt. Ein float pro Kanal zum Beispiel. ...und wandelt dann nur am Schluss in das jeweilige Format um, das man gerne hätte. Zum Beispiel ungefähr so:

    myByteValue = (byte)((myFloatValue * 255.0f) + 0.5f);

    ...um aus dem float ein byte zu machen, in dem alles so gespeichert ist, als ob es ein unsigned Byte wäre.

    Das ist eine einzige Zeile in einer Methode "speicherMichAlsDPXMit8Bit". Und da müsstet Ihr ja sowieso irgendeine Zeile in der Art haben. Unabhängig davon, ob das nun unsigned 8 Bit oder sonst etwas ist.

    0
Anmelden zum Antworten