Wie heisst das?



  • nachtfeuer schrieb:

    Kann man das nicht einfach "Dünnpfiff" nennen?

    Ne. Starke Typisierung ist aus meiner Sicht etwas sehr sinnvolles.



  • Hier geht's aber um Typekonventierung vom Zahlentypen und die Philosophie, mit Informationsverlust umzugehen.



  • Hallo.

    Also es gibt in Java verschiedene primitiver Datentypen :

    byte 1 byte
    short und char 2 byte
    int 4 byte
    long 8 byte
    float 4 byte
    double 8 byte

    Wenn nun von einem kleineren in einen größereb Typen umgewandelt werden soll (int nach float) dann geht das ohne Probleme (impliziertes Konvertieren). Umgekehrt funktioniert das nicht automatisch, da es hier zu INformationsverlusten kommen kann, deshlab expliziet und der User muss es selbst machen.



  • Fischkopf2009 schrieb:

    Hallo.

    Also es gibt in Java verschiedene primitiver Datentypen :

    byte 1 byte
    short und char 2 byte
    int 4 byte
    long 8 byte
    float 4 byte
    double 8 byte

    Wenn nun von einem kleineren in einen größereb Typen umgewandelt werden soll (int nach float) dann geht das ohne Probleme (impliziertes Konvertieren). Umgekehrt funktioniert das nicht automatisch, da es hier zu INformationsverlusten kommen kann, deshlab expliziet und der User muss es selbst machen.

    👍

    Das geht bei Java nicht, weil eine Typensicherheit gegeben ist. Deshalb nur explizit casten:

    int a = 1;
    float b = 0.0F;
    b = a; // ok, da float höheren Wertebereich hat
    a = (int)b; // auch ok, da Nachkomma abgeschnitten wird und Werteüberlauf zugelassen wird
    

    So läuft das nicht nur mit den primitiven Typen, sondern auch mit Objekten. (Ist ja in C++ egal, da man alles mit Pointern lösen kann.)

    Object c = null;
    JFrame f = new JFrame("abc");
    c = (Object)f; // geht, da alle Objekte von Object abgeleitet sind. Zusätzliche Eigenschaften von JFrame werden unsichtbar.
    


  • die Betonung liegt auf Unsichtbar...
    Damit kann man ganz viel mist machen.
    Ich kann den Sinn dieser Möglichkeit einfach nicht Nachvollziehen.

    Mit Interfaces und generics konnte ich das bisher immer verhindern...
    Aber vllt hatte ich einfach noch nicht die richtige Aufgabe...



  • shadow schrieb:

    Das geht bei Java nicht, weil eine Typensicherheit gegeben ist. Deshalb nur explizit casten:

    int a = 1;
    float b = 0.0F;
    b = a; // ok, da float höheren Wertebereich hat
    a = (int)b; // auch ok, da Nachkomma abgeschnitten wird und Werteüberlauf zugelassen wird
    

    So läuft das nicht nur mit den primitiven Typen, sondern auch mit Objekten. (Ist ja in C++ egal, da man alles mit Pointern lösen kann.)

    Object c = null;
    JFrame f = new JFrame("abc");
    c = (Object)f; // geht, da alle Objekte von Object abgeleitet sind. Zusätzliche Eigenschaften von JFrame werden unsichtbar.
    

    Willkommen in der Steinzeit von Java. Ausversehen mal zu tief casten und die JVM schmeißt uns mit Exeception zu, sehr schöne Typesicherheit *gg*



  • shadow schrieb:

    Object c = null;
    JFrame f = new JFrame("abc");
    c = (Object)f; // geht, da alle Objekte von Object abgeleitet sind. Zusätzliche Eigenschaften von JFrame werden unsichtbar.
    

    Das Beispiel ist nicht so sinnvoll, da ich genauso schreiben kann: c = f;
    Interessant wird es nur beim Downcast: f = (JFrame) c;

    Sqwan schrieb:

    die Betonung liegt auf Unsichtbar...
    Damit kann man ganz viel mist machen.
    Ich kann den Sinn dieser Möglichkeit einfach nicht Nachvollziehen.

    Hä erklär mal was man für "mist" damit machen kann? Das ganze nennt sich nunmal Polymorphie.

    Zeus schrieb:

    Willkommen in der Steinzeit von Java. Ausversehen mal zu tief casten und die JVM schmeißt uns mit Exeception zu, sehr schöne Typesicherheit *gg*

    Huh, ja richtig, was soll sie denn sonst machen? Warten bis ich eine Methode aufrufen will und dann erst sterben? Zu tief casten ist halt ein Programmierfehler den ich dann beheben muss wenn mir exceptions fliegen...



  • BierzeltOmi schrieb:

    Zeus schrieb:

    Willkommen in der Steinzeit von Java. Ausversehen mal zu tief casten und die JVM schmeißt uns mit Exeception zu, sehr schöne Typesicherheit *gg*

    Huh, ja richtig, was soll sie denn sonst machen? Warten bis ich eine Methode aufrufen will und dann erst sterben? Zu tief casten ist halt ein Programmierfehler den ich dann beheben muss wenn mir exceptions fliegen...

    Die Notwenigkeit runterzucasten ist schon schlechtes Sprachdesign - von daher lassen wir's lieber 🙂



  • Zeus schrieb:

    BierzeltOmi schrieb:

    Zeus schrieb:

    Willkommen in der Steinzeit von Java. Ausversehen mal zu tief casten und die JVM schmeißt uns mit Exeception zu, sehr schöne Typesicherheit *gg*

    Huh, ja richtig, was soll sie denn sonst machen? Warten bis ich eine Methode aufrufen will und dann erst sterben? Zu tief casten ist halt ein Programmierfehler den ich dann beheben muss wenn mir exceptions fliegen...

    Die Notwenigkeit runterzucasten ist schon schlechtes Sprachdesign - von daher lassen wir's lieber 🙂

    Nein, es ist schlechtes Programmdesign, aber danke trotzdem, dass du der Diskussion fernbleibst, wenn du eh nichts zu sagen hast 👍



  • BierzeltOmi schrieb:

    ...

    Genau weil du nicht mal meine Aussage verstanden hast. 🙂
    Früher konnte mal in ein Array nur Objects speichern, ist dann immer wieder schon ein Object zu raten, was drin sein soll und downzucasten, evtl dann noch vorher mit instanceof prüfen, ob's passt... das ist Polymorphie von Feinsten. Zum Glück sind Generics seid 1.5 in Java drin, dass hat die ganze Situation gerettet.



  • Zeus schrieb:

    Früher konnte mal in ein Array nur Objects speichern

    Du verstrickst dich in Unsinn, allerdings hast du recht, dass ich deine Ursprüngliche Aussage

    Willkommen in der Steinzeit von Java. Ausversehen mal zu tief casten und die JVM schmeißt uns mit Exeception zu

    tatsächlich nicht verstanden hab, aber du weigerst dich auch dich mal zu erklären, oder auf meine Antwort einzugehen. Ergo macht das für mich eher wenig Sinn hier noch weiterzulesen... (auch wenn ich gespannt bin was Sqwan noch zu sagen hat...)



  • @BierzeltOmi
    Ich hab wirklich keine Lust mich ständig gegen deine Anschuldigen zu wehren, falls du mir zeigst wie ich in eine ArrayList andere Typen außer Object unterbrigen bin ich sehr glücklich meine Dummheit einzugestehen, aber es wird sehr schwer:
    http://download.oracle.com/javase/1.4.2/docs/api/java/util/ArrayList.html

    public boolean add(Object o)
    public boolean contains(Object elem)
    

    Aber ich seh schon kommen, du zeigst mir ein Upcast ^^
    Die Lösung für viele Casting Problematiken sind Generics, falls es dir nicht hilft, dass zu wissen, das muss'u mal ein Java Experte mit deine Problemstellumg näher beschreiben.



  • Jetzt redest du plötzlich von ArrayList, nicht Arrays, und dazu noch von einer inzwischen fast ein Jahrzehnt alte Version!? Sinn? Du änderst in jedem Post das Thema. Was hat das alles mit der Ursprungsaussage zu tun, auf die ich geantwortet hab? Hier nochmal zum nachlesen...

    BierzeltOmi schrieb:

    Zeus schrieb:

    Willkommen in der Steinzeit von Java. Ausversehen mal zu tief casten und die JVM schmeißt uns mit Exeception zu, sehr schöne Typesicherheit *gg*

    Huh, ja richtig, was soll sie denn sonst machen? Warten bis ich eine Methode aufrufen will und dann erst sterben? Zu tief casten ist halt ein Programmierfehler den ich dann beheben muss wenn mir exceptions fliegen...

    sowas ist mir echt zu dumm, man kann nur hoffen dass du mit deinen Kollegen nicht auch so redest. Gut nacht 🙄



  • Außerdem gibst es eine Array-Class und ein Array-Interface im JDK. Willkommen in der Welt der Mehrdeutigkeit.



  • Lass dich nicht verrückt machen... Ob array oder arraylist nimmt sich nichts...

    Object o[] = new Object[100];

    Wie du es drehst und wendest... Du weißt nie was da drin sein kann...
    Wenn du nun ne klasse schreibst, was auch immer für eine (Ohne generics, denn davon reden wir hier), dann hast da noch mehr probleme...

    public void mirDochWurst(Object o)

    So... Jetzt kannst du nur kacke machen... Und schön dass das Polymorphi heißt. Das macht es nicht besser...
    Du redest dich hier um Kopf und Kragen.

    Denn wir reden hier von, wie Zeus schon sagte, von Steinzeit-Java...
    Und wenn du dich auf den Kopf stellst. In einem heutigen Programm hat sowas:

    public void mirDochWurst(Object o)

    nichts zu suchen...
    Das kannst du, wenn dir nur Methoden wichtig sind mit einem Interface biegen, und wenn du dir über das tatsächliche Objekt sicher sein willst mit Generics lösen.



  • Fischkopf2009 schrieb:

    Wenn nun von einem kleineren in einen größereb Typen umgewandelt werden soll (int nach float) dann geht das ohne Probleme (impliziertes Konvertieren). Umgekehrt funktioniert das nicht automatisch, da es hier zu INformationsverlusten kommen kann, deshlab expliziet und der User muss es selbst machen.

    Von int zu float kommt es auch zu Informationsverlusten oder was denkst du, warum float mehr unterschiedliche Zahlen darstellen kann als int? Der Unterschied ist, dass bei int -> float die letzten Stellen abgeschnitten werden, während bei float -> int die ersten Stellen wegfallen.

    Die Konversionen in Java finde ich trotzdem komisch.

    int a=1, b=2, c;
    c = a + b;    // erlaubt
    
    short a=1, b=2, c,
    c = a + b;    // nicht erlaubt :open_mouth: Was soll das?
    


  • Zeus schrieb:

    Außerdem gibst es eine Array-Class und ein Array-Interface im JDK. Willkommen in der Welt der Mehrdeutigkeit.

    Uff jetzt wird's beschämend. Gut dass die beiden Array Typen wieder nichts mit dem (Unter-Unter-)Thema zu tun haben...

    Sqwan schrieb:

    Lass dich nicht verrückt machen... Ob array oder arraylist nimmt sich nichts...
    [...]

    Du hast Zeus' Punkt nichtmal verstanden. Sein Punkt war, dass er ArrayListen im Steinzeit-Java nicht typisieren kann, natürlich kann ich Arrays typisieren. Und dass Object als Variablen Typ in der Regel ungeeignet ist, hatten wir ja schon geklärt...

    BierzeltOmi schrieb:

    Zeus schrieb:

    Die Notwenigkeit runterzucasten ist schon schlechtes Sprachdesign - von daher lassen wir's lieber 🙂

    Nein, es ist schlechtes Programmdesign



  • kein kenner der antworten schrieb:

    Wie heißt dieses "Phänomen"? Es ist ja sowas ähnliches wie up/downcasting bei Klassen. Oder heißt es hier gar genauso?

    Welches Phänomen?

    Ein float (32bit Gleitkommazahl) kann alle Werte eines 32bit Integer abbilden. Daher kann man in Java implizit einen int-Wert auf Float casten.
    Jedoch kann der Zahlenwert einer Float-Variablen größer als Int.maxValue sein. Daher musst du explizit casten. Aber Vorsicht, es kann zu Verlusten kommen. Das gilt auch in C++.


Anmelden zum Antworten