Hlavní navigace

Názor k článku Novinky v Javě aneb Tygří spáry od Mat - > i kdyz prekladac udela neco jineho, alebrz...

  • Článek je starý, nové názory již nelze přidávat.
  • 7. 11. 2003 17:27

    Mat (neregistrovaný)

    > i kdyz prekladac udela neco jineho, alebrz obe
    > instance budou identicke a vytahnou se z konstant
    > poolu misto aby se vytvareli v dobe volani..)

    muze platit u nekterych prekladacu, pokud se nachazeji u sebe dve konstanty a operator to dovoli (priorita), pak neni problem z nich udelat jednu a tu pak ulozit do poolu konstant

    > Jinak ta staticka valueOf() co jsem mel na mysli je az z 1.5 a pouziva se prave pro boxovaci ucely.

    OK

    > Otazka je, jestli by si kompilator vubec mel takoveto optimalizace dovolit. ...

    Veskere vysledky odvozene od predem danych konstant lze predpocitat. Nehrozi zadne nebezpeci (od toho jsou konstanty a operace povedou vzdy ke stejnemu vysledku).

    Optimalni prekladac by mel umet i

    "Ahoj " + "Jardo, ted je " + 5 + " hodin."

    v dobe prekladu spojit do

    "Ahoj Jardo, ted je 5 hodin."

    bez nebezpeci.

    > ... otazka je, co by to udelalo napr. s vykonosti ap ...

    To je otazka. Jelikoz by kazdy instance 'objektoveho primitivniho typu' byla zaroven i konstantou (viz muj prispevek o neco vyse). Mohl by s ni prekladac zachazet jako s primitivnim typem a jeji metody chapat jen jako operace nad nimi (ve skutecnosti to tak opravdu je). Meli by proste vysadni postaveni mezi tridami stejne jako String. Nejsem si jist co by to presto nestalo nejakou rezii v dobe behu aplikace.

    To vse je jen otazkou semantiky a implementace.

    V implementaci by to byl vzdy primitivni typ. Semanticky by to byl objekt. Rozdil v kodu nepoznas (viz. muj prispevek o neco vyse).

    Nevim jastli pujde v 1.5 napsat:

    Integer a = 5, b = 3;
    odpovida po autoboxingu
    Integer a = new Integer(5), b = new Integer(3);

    a nebo

    Integer c = a + b;
    po unpoxingu a naslednem autoboxingu
    Integer c = new Integer(a.intValue() + b.intValue());

    Pokud bude toto v 1.5 mozne, pak rozdil mezi nimy se vypari a obe dvojce obou prikladu jsou jen syntaktickou variantou teze semantiky.

    Jen by zustaly dvojice jmen pro totez (napr. int a Integer) - alias. Implementovan by ovsem mohl byt jen primitivni typ (napr. int). Prenesla by se tedy vyjimka pro primitivni typy ze syntaxe cisteho objektoveho jazyka do jeho implementace, tzn. navenek jen objektove typy, uvnitr samozrejmne nektere primitivni (tak jako u funkcionalnich jazyku).

    > Rekl bych, ze by nakonec stejne doslo minimalne k
    > vzniku ekvivalentu poli primitiv, a zas by se
    > objevila otazka, co jsou vlastne jejich prvky? A
    > muzu je pouzit jako objekty? A co treba ona drive
    > zminena synchronizace?

    K ekvivalentu poli primitiv by nedoslo. Vzdy by to bylo pole objektu (syntakticky) Implementacne to muze byt cokoliv. Zalezi na fantazii prekladace. Pokud by neexistoval rozdil mezi int a Integer. Pak

    Integer[] = {3, 4, 5, 6};

    Je chapano jako pole objektu Integer (je zaruceno ze tam neni nic nez Integer kontrolou typu vkladanych objektu) pak nevidim duvod proc by to prekladac nenahradil polem intu v pameti.

    Zopakuji, ze je to jen jiny pohled na totez. Primitivni typ a operace nad nim a objekt s metodami.

    U synchronizace bych potreboval vedet co mate na mysli za problem (lepe specifikovat).