abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 06:00 | Nová verze

Byla vydána verze 1.3.0 odlehčeného desktopového prostředí Lumina (Wikipedie, GitHub) postaveného nad toolkitem Qt. Z novinek lze zmínit nový motiv ikon nahrazující Oxygen (material-design-[light/dark]) nebo vlastní multimediální přehrávač (lumina-mediaplayer).

Ladislav Hagara | Komentářů: 0
včera 17:33 | Bezpečnostní upozornění

Před šesti týdny byly publikovány výsledky bezpečnostního auditu zdrojových kódů OpenVPN a nalezené bezpečnostní chyby byly opraveny ve verzi OpenVPN 2.4.2. Guido Vranken minulý týden oznámil, že v OpenVPN nalezl další čtyři bezpečnostní chyby (CVE-2017-7520, CVE-2017-7521, CVE-2017-7522 a CVE-2017-7508). Nejzávažnější z nich se týká způsobu, jakým aplikace zachází s SSL certifikáty. Vzdálený útočník může pomocí speciálně

… více »
Ladislav Hagara | Komentářů: 0
včera 06:55 | Zajímavý projekt

V Edici CZ.NIC vyšla kniha Průvodce labyrintem algoritmů. Kniha je ke stažení zcela zdarma (pdf) nebo lze objednat tištěnou verzi za 339 Kč (připojení přes IPv4) nebo 289 Kč (připojení přes IPv6).

Ladislav Hagara | Komentářů: 6
včera 06:33 | Zajímavý software

Byla vydána verze 2.2.0 svobodného správce hesel KeePassXC (Wikipedie). Jedná se o komunitní fork správce hesel KeePassX s řadou vylepšení.

Ladislav Hagara | Komentářů: 0
včera 06:11 | IT novinky

Vývojář Debianu Henrique de Moraes Holschuh upozorňuje v diskusním listu debian-devel na chybu v Hyper-Threadingu v procesorech Skylake a Kaby Lake od Intelu. Za určitých okolností může chyba způsobit nepředvídatelné chování systému. Doporučuje se aktualizace mikrokódu CPU nebo vypnutí Hyper-Threadingu v BIOSu nebo UEFI [reddit].

Ladislav Hagara | Komentářů: 0
24.6. 01:23 | Komunita

Phoronix spustil 2017 Linux Laptop Survey. Tento dotazník s otázkami zaměřenými na parametry ideálního notebooku s Linuxem lze vyplnit do 6. července.

Ladislav Hagara | Komentářů: 3
23.6. 22:44 | Nová verze

Po třech měsících vývoje od vydání verze 5.5.0 byla vydána verze 5.6.0 správce digitálních fotografií digiKam (digiKam Software Collection). Do digiKamu se mimo jiné vrátila HTML galerie a nástroj pro vytváření videa z fotografií. V Bugzille bylo uzavřeno více než 81 záznamů.

Ladislav Hagara | Komentářů: 1
23.6. 17:44 | Nová verze

Byla vydána verze 9.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 3
23.6. 13:53 | Nová verze

Simon Long představil na blogu Raspberry Pi novou verzi 2017-06-21 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Z novinek lze zdůraznit IDE Thonny pro vývoj v programovacím jazyce Python a především offline verzi Scratche 2.0. Ten bylo dosud možné používat pouze online. Offline bylo možné používat pouze Scratch ve verzi 1.4. Z nového Scratchu lze ovládat také GPIO piny. Scratch 2.0 vyžaduje Flash.

Ladislav Hagara | Komentářů: 1
22.6. 14:24 | Nová verze

Opera 46, verze 46.0.2597.26, byla prohlášena za stabilní. Nejnovější verze tohoto webového prohlížeče je postavena na Chromiu 59. Z novinek lze zmínit například podporu APNG (Animated Portable Network Graphics). Přehled novinek pro vývojáře na blogu Dev.Opera. Oznámení o vydání zmiňuje také první televizní reklamu.

Ladislav Hagara | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (31%)
 (1%)
 (9%)
 (44%)
 (9%)
Celkem 842 hlasů
 Komentářů: 65, poslední 1.6. 19:16
    Rozcestník

    Úvaha o rozdílech mezi Javou a C++

    9.5.2007 19:09 | Přečteno: 7348× | Programování | poslední úprava: 10.5.2007 20:43

    Toto je můj pokus o shrnutí rozdílů mezi Javou a C++, který je především reakcí na tento dotaz v poradně. Žádný z jazyků nehodnotím a setkávám se s oběma přibližně stejně často. Proto jsem se pokusil shrnout několik základních rozdílů, na které jsem si vzpomněl. Samozřejmě bude rozdílů ještě mnohem víc, což mi jistě případní čtenáři připomenou v diskusi.

    Jaký je vlastně rozdíl mezi francouzštinou a angličtinou? Co mají ty dva jazyky společného? Oba píší latinkou. Oba jsou indoevropské. Oba používají některé výrazy z latiny. Ale určitě to neznamená, že lze snadno a rychle „přejít“ z jednoho na druhý.

    Samozřejmě lze najít i vzdálenější jazyky — například Haskell a Java nemají společnou ani tu pomyslnou „latinku“ (čti základní principy syntaxe). I přesto si myslím, že C++ a Java jsou velmi rozdílné, zejména pokud jde o způsob uvažování. Mám za to, že je rozumné nehledat „kozí stezky“ pro přechod a místo toho se pořádně naučit C a C++, popřípadě Javu — podle toho, kterým směrem se kdo vydá. Já jsem zažil ten druhý směr — se znalostí C++ jsem se naučil Javu.

    Už na první pohled, i když zcela vynecháme otázky přenositelnosti a práce s pamětí, vidíme mnoho rozdílů. Java má spoustu pokročilých konstrukcí (generics, anonymní vnitřní třídy, rozhraní, „chytrý“ enum, konstrukce for( : ) pro kontejnery...), které v C++ nejsou přímo podporovány. Zároveň ale existuje ještě větší spousta možností, které má naopak C++ navíc. Jako nejdůležitější rozdíl vnímám existenci statické instanciace u C++. Ta s sebou nese (mimo jiné) fakt, že se typy proměnných v C++ nedělí na základní a referenční a pro každý typ (včetně například int) existuje implicitní konstruktor. (Reference je v C++ vnímána poněkud odlišně, přestože je z pohledu syntaxe velmi blízká referenci v Javě.) Datové typy v C++ jsou rozděleny na základní a složené. V mnoha situacích se oba druhy typů chovají stejně, ale složené typy mají navíc privilegia plynoucí z principů OOP. Z toho dál plyne ohromná spousta důsledků — přetěžování operátorů, implicitní konverze a konverzní operátory, konverzní konstruktory atd.

    Následuje výčet několika záležitostí, které je potřeba při přechodu z jednoho jazyka na druhý správně pochopit. Samozřejmě se mi nepodaří vyjmenovat všechny rozdíly, proto prosím no flame... Zdůrazňuji, že žádný z jazyků nehodnotím a netvrdím, že některý z obou přístupů je „lepší“ nebo „horší“.

    Takhle by se dalo pokračovat donekonečna. O základních rozdílech mezi oběma jazyky byla už napsána spousta knih. Myslím si, že jejich správné pochopení je důležitým předpokladem k využití všech možností obou jazyků.

    Pokud jsem na něco podstatného zapomněl, věřte mi, že jsem to nemyslel zle.

           

    Hodnocení: 92 %

            špatnédobré        

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    9.5.2007 19:33 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    No, možná by se hodilo ještě dopsat něco o rtti v C++ vs reflexe v Javě, o tom, že C++ překladačů existují mraky, kdežto v případě Javy se v drtivé většině případů používá implementace Sunu ... a pokud znáš knihovnu boost, tak ta by si zasloužila zmínku.

    Jinak je to hezký zápisek.
    When your hammer is C++, everything begins to look like a thumb.
    9.5.2007 21:37 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    No, možná by se hodilo ještě dopsat něco o rtti v C++ vs reflexe v Javě, ...

    Ježto rtti neznám a nepoužívám, raději jsem se tomu tématu chytře vyhnul a doufal, že si toho nikdo nevšimne. :-)

    ... o tom, že C++ překladačů existují mraky, kdežto v případě Javy se v drtivé většině případů používá implementace Sunu ...

    Zkoušel jsem Kaffe a někde měli i VM od IBM. Pak je tu gcj. Ať tak nebo tak, počet překladačů mi nepřipadá důležitý z pohledu základních principů jazyka. C++ překladačů je jistě více, ale protože jde o jednu z nejnáročnějších norem vůbec, málokterý ji v rozumném rozsahu splňuje. Já jsem se setkal jen s g++ a icpc, z nichž ten druhý používám nejraději. Samozřejmě jsem potkal i VisualStudio (grr) a slyšel jsem o Borlandu, který je prý třikrát pomalejší než cokoliv jiného, ale tam už můj zájem nesahá.

    a pokud znáš knihovnu boost, tak ta by si zasloužila zmínku.

    Znám a neznám. Několikrát jsem ji kompiloval, ale nikdy jsem ji nepoužil. Proto nemám znalosti na to, abych ji podrobněji popsal.

    Jinak je to hezký zápisek.

    Díky. :-)

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    kozzi avatar 9.5.2007 19:48 kozzi | skóre: 55 | blog: vse_o_vsem | Pacman (Bratrušov)
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    ...Tam musí být kouzelné slůvko virtual u předka i u potomka...
    IMHO toto není úplně pravda. U C++ stačí definovat virtuální funkci jen v základní třídě, u odvozených tříd je automaticky zděděna funkce virtuální.
    Linux je jako mušketýři "jeden za všechny, všichni za jednoho"
    9.5.2007 21:26 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    IMHO toto není úplně pravda. U C++ stačí definovat virtuální funkci jen v základní třídě, u odvozených tříd je automaticky zděděna funkce virtuální.

    Díky za poznámku.

    Máš naprostou pravdu. Jakmile se mi bude chtít v tom blogpostu hrabat, hned to opravím. Napsal jsem tam pěkný galiMatyáš, jak vidím. Skutečně se vygeneruje VMT pro všechny potomky, a to dokonce i u následujících generací. Ba nejen to! Funguje taktéž volání prapotomků z pointerů na potomky, kteří už klíčové slovo virtual nemají. To dokazuje následující snipplet, který jsem otestoval s g++ a icpc.

    #include<iostream>
    
    using namespace std;
    
    class Parent {
    	private:
    		static const char* const MESSAGE;
    	public:
    		virtual void whoami_virt() { cout << MESSAGE << endl; }
    };
    
    class Child : public Parent {
    	private:
    		static const char* const MESSAGE;
    	public:
    		void whoami_virt() { cout << MESSAGE << endl; }
    };
    
    class GrandChild: public Child {
    	private:
    		static const char* const MESSAGE;
    	public:
    		void whoami_virt() { cout << MESSAGE << endl; }
    };
    
    const char* const Parent::MESSAGE = "I am the Parent.";
    const char* const Child::MESSAGE = "I am a Child.";
    const char* const GrandChild::MESSAGE = "I am a GrandChild.";
    
    int main( void ) {
    	Parent	*p1, *p2, *p3;
    	Child	*c1, *c2;
    
    	p1 = new Parent();
    	p2 = new Child();
    	p3 = new GrandChild();
    
    	c1 = new Child();
    	c2 = new GrandChild();
    
    	cout << "Parent from Parent*: ";
    	p1->whoami_virt();
    
    	cout << "Child from Parent*: ";
    	p2->whoami_virt();
    
    	cout << "GrandChild from Parent*: ";
    	p3->whoami_virt();
    
    	cout << "Child from Child*: ";
    	c1->whoami_virt();
    
    	cout << "GrandChild from Child*: ";
    	c2->whoami_virt();
    
    	return 0;
    }
    
    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 03:08 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    Opraveno. Ještě jednou díky za dobrý postřeh.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    9.5.2007 20:03 Dusan
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    ještě bych přidal, že za výhody Javy považuji:
    -rozdělení do package a tím přehledná adresářová struktura
    -v každém souboru může být pouze jedna public třída
    - neexistuje oddelena deklarace(.h), vse nadefinovano v jednom souboru
    no a abych jenom nechválil, tak Javě silně chybí, alespoň pro vědecké použití, přetížení operátorů pro matematické operace např. komplexní čísla
    9.5.2007 20:18 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    - rozdělení do package a tím přehledná adresářová struktura

    To je spíš věcí názoru. Struktura je pěkná, mám-li třeba IDE typu NetBeans nebo Eclipse. Kdybych se ale měl v nějakém Java-unaware prostředí protloukat strukturou typu cz/doména/...subdobény.../projekt/balíček..., asi bych nebyl až tolik nadšený. V každém případě je to skvělý nápad, díky kterému lze udržet všechny .jar soubory konzistentní a vzájemně slučitelné do větších celků.

    - v každém souboru může být pouze jedna public třída

    Snažil jsem se zaměřit spíš na trochu podstatnější věci. Toto mi připadá jako kosmetická záležitost, stejně jako detaily ohledně spouštění programů a podobně.

    neexistuje oddelena deklarace(.h), vse nadefinovano v jednom souboru

    To jsem pouze krátce zmínil u abstraktních metod. Důležitý rozdíl je spíš bytecode se všemi informacemi versus textový preprocessing. Pravdou je, že javovský přístup má své výhody, protože ne každý C++ kompilátor dokáže za všech okolností inlinovat metody umístěné v jiném souboru. U Javy tento problém odpadá.

    no a abych jenom nechválil, tak Javě silně chybí, alespoň pro vědecké použití, přetížení operátorů pro matematické operace např. komplexní čísla

    O tom už proběhly četné diskuse a přetěžování operátorů se setkalo se značným odporem. Já ho v C++ používám rád a často a myslím si, že kód je pak přehlednější, ale je to opět věc názoru. Je možné, že někdy v Javě bude - podobně jako šablony, které tam byly přidány ve formě Generics. A řekl bych, že velmi citlivě a s využitím všech možností interpretovaného jazyka.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    9.5.2007 20:29 Dusan
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    se vším souhlasím až na reakci "v každém souboru může být pouze jedna public třída"
    Zde si myslím, že to výrazně zjednodušuje orientaci. Přeci jenom když soubor ve kterém je tato public třída se musí jmenovat stejně je velké plus pro lehkou orientaci ve velkém projektu. V C++ to jde taky, ale není to vynucené kompilátorem.
    Jinak skvělý článek. Dík.
    9.5.2007 22:13 ext3fs
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Jen tak mimo soutez...pripadne mi, ze bud s nekym zavodis, nebo zavodis sam se sebou. Protoze at napise kdokoli cokoli, tak to proste nevezmes (uz asi z principu) i za cenu, ze by jsi pod to napsal uplne to same svym slovem. A nebo si chces jen tak povidat...
    9.5.2007 22:35 Dusan
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    no jasně že si chci pokecat, konečně někdo na úrovni :-)
    10.5.2007 09:49 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    j-rozdělení do package a tím přehledná adresářová struktura
    -v každém souboru může být pouze jedna public třída
    Java vynucuje, v C++ umožňuje.

    (njn, ľudia často inklinujú k totalite, aby náhodou nemuseli premýšľať)

    10.5.2007 15:21 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    Java vynucuje, v C++ umožňuje.

    (njn, ľudia často inklinujú k totalite, aby náhodou nemuseli premýšľať)

    Neviděl bych to tak tragicky. Ať se nám to líbí nebo ne, přes 40% software na zakázku dnes vzniká v Javě. Ne každý v ní programuje dobrovolně a ne každý musí v té „totalitě“ pobývat trvale. Btw. nemyslím si, že by programátoři v Javě nemuseli přemýšlet. :-)

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 15:34 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    40% ?? hmm, to by som chcel vidieť ten zoznam. Samozrejme, s definíciou kritérií hodnotenia množstva (počet znakov a riadkov nepovažujem za relevantný, java je ako politik, veľa rečí a nič podstatné) :-D

    10.5.2007 16:29 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    Já taky neříkám, že se mi to líbí. :-) Java už z principu nemůže vytvořit něco „podstatného“ (kernel, profesionální (a rychlý) grafický software). To není bug, to je feature.

    Myslím, že těch 40% bylo vyjádřeno podle objemu investic do software na zakázku, nikoliv podle počtu řádků. Je spousta firem, které v Javě programují a docela je chápu. Na zadání typu „udělejte nám něco, co bude fungovat na všech pěti našich dnešních platformách i na těch, co přijdou za pět let“ je těžké odpovědět jiným způsobem.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 17:20 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    lol, <joke>nie ste náhodou PR zamestnanec Sun-u?</joke>
    Java rozhodne nebeží na ľubovoľnej platforme, pamatám si časy (ani nie 5 rokov dozadu), keď to bolo Write once, run twice. Java je imho hodne používaná, pretože dodávateľ sw je zároveň dodávateľ hw. Aha, zdá sa vám to pomalé? O tom v zmluve nič nebolo, to si musíte kúpiť aj tento supernabúchaný stroj, ...

    10.5.2007 20:23 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    Ad. joke: Ne. :-) Kromě toho přece existuje .NET / Mono, což je podobná technologie. Kdekdo chce mít něco v .NET. Je to neefektivní, ale nedá se s tím nic dělat.

    Java rozhodne nebeží na ľubovoľnej platforme, pamatám si časy (ani nie 5 rokov dozadu), keď to bolo Write once, run twice.

    Je dobré si uvědomit, že C++ vzniklo v roce 1985 a Java v roce 1995. Tomu odpovídá stupeň vývoje těchto jazyků a jejich podpory na různých platformách. Java běží na několika nejpoužívanějších UNIXech včetně Mac OS X, na mobilních zařízeních, na serverových farmách a dokonce i pod Windows. Těch platforem bych dnes určitě napočítal dobrých deset.

    Za dalších deset let si umím docela dobře představit třeba hardwarový interpret Javy či .NET/Mono v každém procesoru. Ne že by se mi ta myšlenka líbila. Jen se mi zdá, že to vidíte moc černobíle. Java nemá pouze špatné stránky. Je to určitý prostředek ke splnění určitého účelu.

    Java je imho hodne používaná, pretože dodávateľ sw je zároveň dodávateľ hw.

    Nooo, tohle snad nemůžete myslet vážně... Java se přece používá v opačných případech. Kdyby někdo chtěl zákazníkovi vnutit supernabouchaný stroj, udělá ten software tak, aby na žádném jiném HW neběžel, a Javě se vyhne na sto honů.

    Pokud jde o stížnosti na údajnou pomalost Javy... Spíš bych to přičítal neschopnosti (některých, zdůrazňuji některých) javovských programátorů. Benchmarky většinou ukazují, že Java je v průměru přibližně 1,5krát pomalejší než C++ při provádění téhož algoritmu. Tenhle má ještě mnohem zajímavější výsledky.

    Je to stejné jako stěžovat si třeba na pomalost Haskellu. Ano, je pomalý. No a co? Pokud ho vyžaduje úkol, na kterém pracuju, prostě ho použiju a nemám co řešit.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    Luboš Doležel (Doli) avatar 10.5.2007 21:50 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Tenhle má ještě mnohem zajímavější výsledky.
    Když vidím test s názvem Hash a 2x lepší výsledek u Javy, říkám si, že s C testem/programem muselo být něco zatraceně v nepořádku.
    10.5.2007 22:30 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    Záleží to na ohromné spoustě věcí. Jednou jsem kompiloval (do jednoho školního předmětu) interpret jakéhosi bytecode. Ten bytecode byl výstupem z kompilátoru Packalu napsaného pomocí Flexu a Bisonu. Rozdíl v rychlosti mezi g++ -gg -O0 a icpc -xB -O3 byl na mém stroji šestinásobný.

    Benchmark tedy lze velmi snadno podvrhnout, což se asi v tomto případě stalo. Pořád jsem ale přesvědčen, že Java není tak beznadějně pomalá, jak někteří tvrdí. Asi budu muset jednou udělat nějaký benchmark sám... Nebo radši ne, protože je mi to jedno. Když už Javu používat musím, tak ji používám a hotovo.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 23:48 Kyosuke | skóre: 28 | blog: nalady_v_modre
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Pokud jde o stížnosti na údajnou pomalost Javy... Spíš bych to přičítal neschopnosti (některých, zdůrazňuji některých) javovských programátorů. Benchmarky většinou ukazují, že Java je v průměru přibližně 1,5krát pomalejší než C++ při provádění téhož algoritmu. Tenhle má ještě mnohem zajímavější výsledky.
    Zajímalo by mě, jak by v dnešní době dopadl tenhle test. Je to přeci jen už dost dlouho, všechna tři prostředí od té doby ušla nepochybně pěkný kus cesty. Nicméně těch neschopných javovských programátorů tehdy muselo být opravdu požehnaně. ;-)
    11.5.2007 00:19 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Nicméně těch neschopných javovských programátorů tehdy muselo být opravdu požehnaně. ;-)

    Tohle je trochu jiný problém, který s programátory nesouvisí. SUN dlouhou dobu neměl JIT (Just-in-Time kompilátor). Nevím přesně, kdy ho vyvinuli a ve které verzi JVM se poprvé objevil. (A nechce se mi to teď hledat.) Před zavedením JIT měla Java problémy s výkonem. Tenkrát začaly vznikat různé alternativní implementace JVM (např. Kaffe), které nějakou formu JIT kompilace měly dříve než SUN. Toto vylepšení zvýší rychlost pětinásobně až třicetinásobně podle typu algoritmu.

    Otázka ovšem je, zda náhodou tento benchmark není podobně problematický jako ten, který jsem uvedl já. Pokud by Lisp umožňoval zázraky, o čemž svědčí grafy v benchmarku, proč dnes ještě není masově rozšířený? Existoval mnohem dříve než Java. Nebyl to náhodou první vyšší jazyk vůbec (někdy koncem 50. let)? Těžko říct, kde je pravda.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    11.5.2007 00:31 Kyosuke | skóre: 28 | blog: nalady_v_modre
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Tohle je trochu jiný problém, který s programátory nesouvisí. SUN dlouhou dobu neměl JIT (Just-in-Time kompilátor). Nevím přesně, kdy ho vyvinuli a ve které verzi JVM se poprvé objevil. (A nechce se mi to teď hledat.) Před zavedením JIT měla Java problémy s výkonem. Tenkrát začaly vznikat různé alternativní implementace JVM (např. Kaffe), které nějakou formu JIT kompilace měly dříve než SUN.
    Tohle je dělané na verzi 1.2 - už JIT, ale ještě asi ne HotSpot. Ale jak říkám, kus cesty ušly všechny implementace, kdo ví, jak by to dopadlo dnes. Skoro mám chuť napsat autorovi o přeměření. ;-)
    Toto vylepšení zvýší rychlost pětinásobně až třicetinásobně podle typu algoritmu.
    Tohle je pro mě tvrzení z kategorie "Náš nový jogurt je o celých 23,7 % krémovější." :-D I šestinásobné rozpětí u nespecifikované přesné technologie a konkrétní aplikace mi přijde jako odvážně "přesné". ;-)
    Otázka ovšem je, zda náhodou tento benchmark není podobně problematický jako ten, který jsem uvedl já.
    Otázka ovšem je, zda vůbec existuje něco jako "neproblematický benchmark". :-D
    11.5.2007 08:23 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Toto vylepšení zvýší rychlost pětinásobně až třicetinásobně podle typu algoritmu.
    Tohle je pro mě tvrzení z kategorie "Náš nový jogurt je o celých 23,7 % krémovější." :-D I šestinásobné rozpětí u nespecifikované přesné technologie a konkrétní aplikace mi přijde jako odvážně "přesné". ;-)
    Leoš to na Abíčku nedávno omylem zkoušel, a povolením JIT došlo ke znatelnému nárůstu výkonu :-)
    xxx avatar 10.5.2007 00:43 xxx | skóre: 42 | blog: Na Kafíčko
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Ad synchronizace a komunikace. Ohebnost Javovskych threadu je az neuveritelna. Letos jsem v jednom predmetu pricichl k threadum a procesum v C a je to neco uplne jineho. Zabit korektne posixovsky thread chce obcas hodne trpelivosti.
    Please rise for the Futurama theme song.
    10.5.2007 01:53 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    imho java nema s c++ spolocnu ani tu latinku... tie dva jazyky spajaju tak maximalne bodkociarky a kucerave zatvorky :)
    10.5.2007 02:08 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    Srovnej to například s Prologem nebo Haskellem... Nebo třeba se Scheme (odrůda Lispu) a jeho krásnými štrůdly závorek. Přece jen mají Java a C++ společné konstrukce jako if-else, for, while, switch, syntaxi metod a příkazů, názvy základních číselných typů, přístup k polím, výrazy a operátory. Syntaxe je jednorozměrná, tj. bílé místo nehraje roli (narozdíl např. od Haskellu). Oba jazyky popisují algoritmus, nikoliv samotný problém. To je až moc společných znaků, se mi zdá.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 02:12 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    Hmmm, pardon, s tím přístupem k polím jsem to hodně přepískl... Spíš bych měl říct: Za jistých okolností lze k polím v C++ přistupovat jako k polím v Javě, ale nebývá to vždy vhodné. (Obrácená „implikace“ samozřejmě neplatí.)

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 04:15 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    no vidis... ked si popisoval len tie spolocne, tak to vyslo na asi 20x menej textu... ;) ale nie, zartujem... inak vcelku fajn clanok, len skoda nietkorych nepresnosti / polopravd / nedovysvetlenych myslienok... napr:

    • operator new nieje jediny sposob vytvarania objektov v jave, ide to aj cez reflexiu, klonovanie, deserializaciu...
    • "složené typy mají navíc privilegia plynoucí z principů OOP": ake privilegia ma struct alebo union???
    • "Za jistých okolností lze k polím v C++ přistupovat jako k polím v Javě..." akych?? mozno tebe sa to zda jasne, ale ja neviem co myslis...
    • volanie metod sa v jave NECHOVA vzdy virtualne... staticke metody sa nechovaju virtualne, dokonca funguje ((Integer) null).valueOf(1)
    • porovnavanie destruktorov s finalize sa mi zda tiez dost nestastne... aspon by sa oplatilo poznamenat ze finalize je callback...
    • "V Javě musí být abstraktní každá třída, která obsahuje alespoň jednu abstraktní metodu"... takisto aj v c++
    • "Pokud bychom v Javě každou třídu umístili do samostatného balíčku, byl by význam klíčových slov public, private a protected téměř stejný"... no neviem co myslis tym "téměř" ale ak uz das triedy do hocijakeho balicka, nic to na private public a protected v jave nezmeni...

    a dalej: java nema kanaratske triedy "fiend", c++ nema "final", java nema struktury, c++ nema multi-level break/continue, java nema goto (ale asi ho chcela mat, kedze je to rezervovane slovo)... a celkovo je toho viac co java nema

    ale inak ako hovorim, vcelku vpoho clanok... taky vedecko/popularny

    10.5.2007 09:16 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    operator new nieje jediny sposob vytvarania objektov v jave, ide to aj cez reflexiu, klonovanie, deserializaciu...
    Asi bylo myšleno to, že nejde vytvořit objekt jinak, než voláním konstruktoru.
    volanie metod sa v jave NECHOVA vzdy virtualne... staticke metody sa nechovaju virtualne, dokonca funguje ((Integer) null).valueOf(1)
    Statické metody se nikdy nevolají na instanci objektu, ale na třídě – klidně je tedy možné říci, že se volají virtuálně. Váš příklad se tedy přeloží jako
    Integer.valueOf(1);
    
    10.5.2007 11:28 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    nie, objekty sa DAJU vytvarat inak ako volanim konstruktora.

    Statické metody se nikdy nevolají na instanci objektu, ale na třídě – klidně je tedy možné říci, že se volají virtuálně.

    o tom by sa tiez dalo diskutovat, ale podstatne je ze pri tomto volani sa nepouziva ziadna tabulka na zistenie toho co sa ma volat, takze to NIEJE virtualne!! uz pri kompilacii sa PRESNE rozhodne co sa bude volat!!!

    takisto volanie private metod NIEJE virtualne!

    10.5.2007 11:47 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    No, způsoby jsou odlišné, ale nakonec je instance stejně na haldě (a navíc, že ve všech uvedených příkladech je to new pouze skryté), narozdíl od C++, kde jsou na haldě jenom instance vytvořené dynamicky.
    When your hammer is C++, everything begins to look like a thumb.
    10.5.2007 11:47 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Mělo tam být ... navíc se domnívám, že
    When your hammer is C++, everything begins to look like a thumb.
    10.5.2007 12:35 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    nie nieje! ak v jave deserializujes objekt, ziadny konstruktor sa nezavola!!! a objekt je na svete...
    10.5.2007 13:24 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    To máte pravdu, na to jsem zapomněl. Resp. onu klasickou serializaci dle java.io.Serializable jsem nikdy nepotřeboval ;-)
    10.5.2007 14:25 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Jenže ona nám tu zůstává otázka, jak asi vznikla ta úplně první instance, kterou jsme potom serializovali? ;-)
    When your hammer is C++, everything begins to look like a thumb.
    10.5.2007 14:34 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Deserializovať sa dá aj z dierneho štítku, serializácia mohla prebehnúť manuálne :-D
    10.5.2007 15:34 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    No dobře, tuto možnost jsem skutečně nevzal v potaz :-D
    When your hammer is C++, everything begins to look like a thumb.
    10.5.2007 11:56 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Bavíme se ještě stále o Javě? Jak jinak se dají objekty vytvořit, než voláním (třeba skrytým) konstruktoru?

    Tabulka virtuálních metod se nepoužívá i v jiných případech (pokud kompilátor/JIT zjistí, že není možné volat jinou metodu, tedy např. v souvislosti s final). Podle existence tabulky virtuálních metod bych tedy nerozlišoval, kdy jde o virtuální metodu a kdy ne. I na statické metody se lze dívat, jakoby byly virtuální (splňují všechny požadavky na virtuální metody), takže nevidím důvod, proč je tak nenazvat a vymýšlet nějakou speciální výjimku.
    10.5.2007 12:28 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    co su: "všechny požadavky na virtuální metody"?? staci linka na zoznam
    10.5.2007 09:56 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    jednoducho povedané, struct je ako class s default public.

    10.5.2007 16:22 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    operator new nieje jediny sposob vytvarania objektov v jave, ide to aj cez reflexiu, klonovanie, deserializaciu...

    Reflexe a klonování je skrytý new. U té deserializace máš pravdu. Má pointa však byla vtom, že se pro každý nový objekt vyhradí zvlášť paměť, a to vždy na „haldě“. (Zkrátka v místě, kam konkrétní implementace virtuálního stroje ukládá dynamicky alokovaná data.) To platí i pro deserializaci. Objekt v Javě nemůže být nikdy na zásobníku.

    "složené typy mají navíc privilegia plynoucí z principů OOP": ake privilegia ma struct alebo union???

    Struct je skoro přesně totéž co class. Je mezi nimi jediný drobný rozdíl: Prvky struct jsou implicitně public, prvky class jsou implicitně private. Jinak všechno mají stejné - data, konstruktory, destruktory, způsob vzniku... Pokud jde o union, ta si s OOP občas příliš nerozumí, neboť může poškodit různá metadata objektů a odkazy na VMT. To ale hlídá kompilátor. V C++ je union spíš outsider, který byl zděděn z C. V jednoduchých případech ho lze s úspěchem použít, ale většinou se dá nahradit nějakou pokročilejší konstrukcí. Union není složený typ v pravém slova smyslu.

    Těmi privilegii jsem myslel především přetěžování operátorů, které pro základní typy není možné. (Přesněji řečeno, přetížený binární operátor může mít jeden operand základního typu.) To platí pro struct i class. Další odlišnosti jsou spíš technického rázu - automatické volání konstruktorů a destruktorů při instanciaci na zásobníku, posun pointerů při konverzi z potomka na předka u vícenásobné dědičnosti a mnohé další, na které si teď nevzpomínám.

    "Za jistých okolností lze k polím v C++ přistupovat jako k polím v Javě..." akych?? mozno tebe sa to zda jasne, ale ja neviem co myslis...

    Dvojrozměrné pole v C++ à la Java: Naalokuješ si pole pointerů na jednorozměrné pole. Pak postupně alokuješ jednorozměrná pole. Z pointeru na pole pointerů lze pomocí dvou párů hranatic přistupovat k jednotlivým prvkům jednotlivých jednorozměrných polí. Kdybys chtěl kontrolu mezí, stačí si udělat třídu, u které přetížíš operátor hranatice []. Taková třída pak může obsahovat pole a kontrolovat meze. (Hranatice by měla vracet referenci, aby fungovalo správně přiřazení i použití v aritmetických výrazech.) Takže takhle jsem to myslel.

    (V případě stejné délky všech prvků (99,9% případů) je samozřejmě rozumné v C++ naalokovat normání dvojrozměrné pole. Tam je pak pointer na jeho nultou jednorozměrnou složku. Pak funguje správně dvojice hranatic i pointerová aritmetika.)

    volanie metod sa v jave NECHOVA vzdy virtualne... staticke metody sa nechovaju virtualne, dokonca funguje ((Integer) null).valueOf(1)

    Volat statické metody přes referenci se nedoporučuje. Já takové věci nedělám a mám za to, že by to skončilo v nejlepším případě warningem.

    porovnavanie destruktorov s finalize sa mi zda tiez dost nestastne... aspon by sa oplatilo poznamenat ze finalize je callback...

    V C++ je při instanciaci mimo haldu každý konstruktor i destruktor de facto callback. :-) Takže mi to nepřipadá důležité nebo neobvyklé. Srovnání není šťastné, ale žádné lepší mě nenapadlo. Má snad Java ještě jiný ekvivalent destruktoru?

    "V Javě musí být abstraktní každá třída, která obsahuje alespoň jednu abstraktní metodu"... takisto aj v c++

    Ano, ale její deklarace se v C++ neoznačuje žádným speciálním klíčovým slovem. Spíš jsem měl napsat „musí být označena za abstraktní“. To by bylo přesnější.

    "Pokud bychom v Javě každou třídu umístili do samostatného balíčku, byl by význam klíčových slov public, private a protected téměř stejný"... no neviem co myslis tym "téměř" ale ak uz das triedy do hocijakeho balicka, nic to na private public a protected v jave nezmeni...

    Nikoliv, nemáš pravdu. Modifikátor protected v Javě zpřístupní data nejen pro potomky dané třídy, ale i pro všechny třídy daného balíku. To je rozdíl oproti C++. Takže na public a private to opravdu nic nezmění, ale na protected ano.

    java nema kanaratske triedy "fiend", c++ nema "final", java nema struktury, c++ nema multi-level break/continue, java nema goto (ale asi ho chcela mat, kedze je to rezervovane slovo)... a celkovo je toho viac co java nema

    Dokonce nemá ani kamarádské funkce, neboť nemá vůbec žádné funkce vně tříd. Princip kamarádských tříd považuji za nedůležitý a jeho nadměrné použití může znamenat chybu v návrhu. C++ nema final, nýbrž const, který je mu v jistém smyslu podobný. Zejména uvnitř tříd, kde musí být konstanty přiřazeny inicializátorem v záhlaví konstruktoru. (Ale C++ na toto nemá žádnou run-time kontrolu.) Pravda, multilevel break se musí v C++ nahradit nějakým goto, ale člověk ho potřebuje dost vzácně a nepřipadalo mi to podstatné.

    ale inak ako hovorim, vcelku vpoho clanok... taky vedecko/popularny

    Díky. Žádné jiné ambice jsem si nekladl. :-)

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 17:27 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    ad final v Jave, nezdá sa vám to trochu choré?

    k operátorom by snáď bolo vhodné poznamenať možnosť (v C++) zmeniť chovanie new pre špecifické potreby aplikácie (typicky pooling)

    10.5.2007 17:33 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    pre upresnenie: tie použitia, kde finalobmedzuje dedičnosť.
    10.5.2007 19:02 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    ano ten final som mal na mysli a nie nemyslim si ze je to chore :) niekedy proste nechces aby niekto tvoju triedu/metodu dalej pretazoval... proste na to nieje pripravena a nikdy nebude...
    10.5.2007 20:32 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    Tak to abych se ještě rovnou rozepsal o „placement new“, „placement delete“, poolingu, alokátorech u STL...

    Pak zas někdo řekne, že mi tam chybí CORBA a RMI u Javy a pokročilé triky s Generics. Tohle je blogpost, ne kniha. :-(

    ad final v Jave, nezdá sa vám to trochu choré?

    Mně trochu vadí snad jenom to, že má dva výzamy (konstanta a zákaz dědění). Komu se to zdá špatné, nemusí dědění zakazovat. Komu se zdají špatné friend třídy a friend funkce v C++, nemusí je používat. V každém jazyce se něco takového najde.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 19:13 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    ok, dik za doplnenie... ps: za clone za tiez neskryva ziaden new ;)
    12.5.2007 15:39 Miloslav Ponkrác | blog: miloslavponkrac
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Já bych řekl, že hlavní rozdíly mezi destruktorem a finalize řečeny vůbec nebyly. Za prvé od finalize se nedá očekávat, který thread ho vykoná. Za druhé destruktor se provádí prakticky hned jakmile objekt skončí, finalize až za hodně dlouhou dobu. Finalize se nemusí teoreticky dokonce zavolat vůbec. Protože za třetí se destruktory v C++ provádějí ASAP, neexistují v C++ na rozdíl od Javy/.NET žádné potřeby dalšího uvolňování prostředků systému dříve, než se zavolá finalizér (to je ta další podoba destruktoru - třeba v .NET se jmenuje často Dispose()).

    Union je normálně přetížitelný, například je pro něj dají přetěžovat normálně operátory (viz STL a gcc), může mít metody, atd.. A je to velmi užitečný prvek na jeden ze způsobů práce s bitovým polem.

    Já bych dodal ještě jako hlavní rozdíl chybějící typedef v Javě, pro mě to byl dost bolestný prvek.
    12.5.2007 17:12 Andrej | skóre: 44 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    (to je ta další podoba destruktoru - třeba v .NET se jmenuje často Dispose()).
    Těch rozdílů jsem si samozřejmě vědom, ale nešlo mi o přesné srovnání destruktoru s finalize. Jen jsem chtěl přiblížit odlišnou filosofii práce s prostředky. Metoda dispose() je častým a obvyklým voláním v rozhraních, která používají JNI (Java Native Interface), například v SWT. V těchto případech ale slouží de facto k uvolnění prostředků v nějakém nativním kódu mimo JVM, takže do specifikace Javy nepatří a tím méně je (z pohledu Javy) destruktorem.
    Union je normálně přetížitelný, například je pro něj dají přetěžovat normálně operátory (viz STL a gcc), může mít metody, atd.. A je to velmi užitečný prvek na jeden ze způsobů práce s bitovým polem.

    Tohle slyším poprvé a je to zajímavé. Nikdy jsem nic podobného nepoužil. To budu muset vyzkoušet.

    Já bych dodal ještě jako hlavní rozdíl chybějící typedef v Javě, pro mě to byl dost bolestný prvek.

    Pravdou je, že třeba TreeMap< String, LinkedList< String > > není nejlepší název typu... :-)

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    10.5.2007 08:58 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Díky za pěkný zápisek. Možná bych dodal ještě to, že v Javě může programátor snadno používat spousty složitějších konstrukcí, a nemusí jim zrovna moc rozumět (generiky, synchronizace, enum). Snad se nepletu, ale v C++ používat třeba reference nebo šablony, aniž by o tom člověk alespoň něco trochu věděl, asi moc nejde. (V obou případech mám na mysli "užívat" skutečně v tomto smyslu - někdo už přede mnou naprogramoval kontejner, a já ho užívám tím, že do něj vkládám prvky, mažu je a vyhledávám.) V Javě se musí podrobnostmi začít programátor zabývat až v okamžiku, kdy začne sám implementovat nějakou složitější třídu používající generiky, složitější enum apod. Asi nejzrádnější je to u synchronized, které může neznalý programátor*) nacpat kde se dá, běh programu tím neuvěřitelně zpomalí, ale ve skutečnosti stejně bude docházet ke konfliktům vláken.

    *) Což je relativní pojem. Neuvěřitelné množství lidí má třeba představu, že konstrukce objektu je atomická operace z hlediska konkurenčního přístupu vláken. V Javě 5 už je to upraveno tak, že přiřazení reference nově vzniklého objektu do proměnné proběhne vždy až po úplné konstrukci objektu. Takže pokud neunikne "ven" (mimo this) reference na objekt během jeho konstrukce, dostane se od Javy 5 k referenci "z venku" kdokoli až v okamžiku, kdy je objekt plně zkonstruován, takže to atomickou operaci připomíná. Takže v Javě 5 už funguje správně oblíbená ale v Javě zbytečná zpožděná (lazy) naivní inicializace jedináčka (singletonu).
    Josef Kufner avatar 10.5.2007 09:39 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Jo a pak ty programy podle toho vypadají.
    Hello world ! Segmentation fault (core dumped)
    10.5.2007 09:52 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    To se řeší pořád dokola. Máme dost hackerů, kteří budou psát pořádné programy ve strojovém kódu? Nemáme. Potřebujeme ty programy? Asi ano. Tak holt některé věci musí psát lidi, kteří nejsou těmi nejlepšími programátory na světě. Důležité je, aby u sebe měli někoho, kdo dokáže problémové věci rozpoznat a hlavně je pak napsat pořádně. Pokud mají takovíhle lidé k dispozici platformu, která jim některé druhy chyb prostě nedovolí udělat (nebo vyrobení takové chyby značně zesložití), je to jedině dobře. Existuje totiž spousta lidí (dokonce je jich drtivá většina), pro které není cíl programování samé, ale cílem je program, který řeší nějaký problém. Na silnice taky nepouštíme jen profesionální závodníky, ale taky do aut montujeme automatické převodovky, posilovače řízení, ABS a jiné třípísmenné zkratky ;-) , aby auto mohli používat i horší řidiči. A to auta dokáží zabíjet, což se nějakému redakčnímu systému nebo účetnictví asi nepovede.
    10.5.2007 11:42 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    nechcem vyvolavat flame, ale:

    v jave mozes kodit bez toho aby si vedel ako funguje a nedostanes segmentation fault. ale tvrdenie ze c++ koderi su ti najlepsi (pretekari) na svete a java koderi su ti ktory ani poriadne nevedia co robia, to je imho trochu silna kava... popravde povedane java ma tiez svoje zakutia a finty o ktorych VELA ludi nevie (ako som si vsimol ani ty)... ich programovanie ma potom podobne katastrofalne nasledky ako spominany segfault...

    10.5.2007 12:06 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Nic takového jsem snad netvrdil… Tvrdil jsem, že napsat něco bez znalostí detailů implementace půjde spíš v Javě, než v C++. Ale že i u projektů v Javě se najdou místa, kde je potřeba o běhovém prostředí apod. vědět víc – jako typické oblasti jsem uvedl vícevláknové zpracování, nebo implementace složitějších tříd využívajících generiky nebo vnitřní třídy a enumy.

    Jestli jsem tady v diskuzi předvedl neznalost nějakého zákoutí nebo finty, rád se nechám poučit – nepředpokládám, že už jsem objevil všechna zákoutí a finty Javy ;-)
    10.5.2007 12:47 xmas_spirit
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++

    odporucam: Effective Java Programming Language Guide a Java(TM) Puzzlers: Traps, Pitfalls, and Corner Cases

    taktiez by som privital nejaku linku na clanok o tom atomickom vytvarani objektov v java 5

    10.5.2007 13:43 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Safe construction techniques, Fixing the Java Memory Model, Part 2 (který je trochu zvláštní, protože sice popisuje technické detaily, ale chybí v něm ta základní věc, totiž jak je objekt v Javě konstruován), JSR 133 (Java Memory Model) FAQ
    10.5.2007 21:25 Andrei Badea | skóre: 5 | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Myslel jsem, ze neni obecne pravda, ze prirazeni reference do promenne probiha az po provedeni konstruktoru. V novem memory modelu to tak asi je pro final a volatile promenne a pro tridy s final promennymi. Ale nevidim duvod aby to platilo pro vsechny, tedy i nesynchronizovane promenne. Vlastne nevidim duvod aby to platilo ani pro promenne inicializovane uvnitr synchronized bloku. Kdyby to platilo, double-checked locking by v novem memory modelu fungoval aniz by promenna drzici instanci singletonu musela byt volatile (viz priklad v JSR 133 FAQ: vlakno ctouci "instance" by vzdy precetlo null nebo referenci na uplne vytvoreny objekt).

    Odkud z odkazovanych dokumentu toto vyplyva? Nejvice se tomu blizi "initialization safety", ale to se IMHO tyka pouze trid z final promennymi.
    Heureux qui, comme Ulysse, a fait un beau voyage.
    11.5.2007 08:19 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Myslel jsem, ze neni obecne pravda, ze prirazeni reference do promenne probiha az po provedeni konstruktoru.
    To je celkem dobrý předpoklad, taky jsem si to myslel. A je to rozhodně bezpečnější, než se (jako většina programátorů) bez jakéhokoli ověření a zamyšlení domnívat, že to obecně pravda je. Tohle je právě věc, která mi ve všech odkazovaných článcích chyběla, protože je to na celé věci to nejpodstatnější – pokud by se objekt vytvářel tak, že se alokuje paměť, vrátí se reference na tu paměť a teprve pak začne probíhat inicializace a konstruktor (a teprve pak skončí příkaz instance = new Object()), je změna pořadí příkazů v tomto případě nepodstatný detail :-)

    Nicméně mám pro vás dobrou zprávu, aktuální specifikace Javy zaručuje, že to obecně pravda je ;-)
    Just before a reference to the newly created object is returned as the result, the indicated constructor is processed to initialize the new object using the following procedure:
    1. Assign the arguments for the constructor to newly created parameter variables for this constructor invocation.
    2. If this constructor begins with an explicit constructor invocation of another constructor in the same class (using this), then evaluate the arguments and process that constructor invocation recursively using these same five steps. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason; otherwise, continue with step 5.
    3. This constructor does not begin with an explicit constructor invocation of another constructor in the same class (using this). If this constructor is for a class other than Object, then this constructor will begin with an explicit or implicit invocation of a superclass constructor (using super). Evaluate the arguments and process that superclass constructor invocation recursively using these same five steps. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, continue with step 4.
    4. Execute the instance initializers and instance variable initializers for this class, assigning the values of instance variable initializers to the corresponding instance variables, in the left-to-right order in which they appear textually in the source code for the class. If execution of any of these initializers results in an exception, then no further initializers are processed and this procedure completes abruptly with that same exception. Otherwise, continue with step 5. (In some early implementations, the compiler incorrectly omitted the code to initialize a field if the field initializer expression was a constant expression whose value was equal to the default initialization value for its type.)
    5. Execute the rest of the body of this constructor. If that execution completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, this procedure completes normally.
    Double checked locking by díky tomu fungovat měl, pokud někoho nenapadne vložit do statické proměnné referenci přímo z konstruktoru ("únik this"). Nicméně problém s klasickou pozdní inicializací jedináčka i s double checked locking je hlavně ten, že se to, zda je objekt kompletně inicializován, posuzuje podle toho, zda reference na něj je či není null, navíc se to děje úplně bez synchronizace. Což tedy v novém paměťovém modelu už bude shodou okolností fungovat, nicméně pořád si myslím, že správný postup je mít statickou proměnnou AtomicBoolean, kterou teprve v případě prokazatelně správné inicializace objektu nastavím na true. Pokud tedy z nějakého důvodu nechci použít pozdní inicializaci implementovanou už v JVM, které nevytvoří instanci třídního objektu dřív, než je ta třída někde potřeba.
    11.5.2007 22:29 Andrei Badea | skóre: 5 | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Porad se mi to nezda.

    Odkazovany text existuje i v druhe edici JLS z roku 2000, tedy uz pred vydanim Javy 5. Nelze ho tedy povazovat za dukaz toho, ze od Javy 5 se reference prirazuje az po uplnem vytvoreni objektu. Zda se mi, ze text popisuje situaci na konceptualni urovni, tedy tak, jak se jevi programatorovi jednovlaknove aplikace.
    Double checked locking by díky tomu fungovat měl
    Take se mi to tak jevi. Jenze to se nikde nedoctete. Jak v JSR 133 FAQ, tak i zde se uvadi jako spravne reseni udelat promennou singletonu ("instance") volatile.
    Nicméně problém s klasickou pozdní inicializací jedináčka i s double checked locking je hlavně ten, že se to, zda je objekt kompletně inicializován, posuzuje podle toho, zda reference na něj je či není null, navíc se to děje úplně bez synchronizace.
    Prave v tom je kamen urazu. Bez synchronizace bude zapis pod zamkem, ale cteni mimo zamek, coz je dle JLS data race (zapis a cteni nejsou v relaci happens-before). Program tedy neni spravne synchronizovan.

    Reseni s AtomicBoolean IMHO neprinasi zadnou vyhodu. AtomicBoolean ma podobny overhead jako volatile, to uz rovnou muzete promennou singletonu udelat volatile. Nelibi se mi ale, ze tam porad bude data race. Fungovat by to asi melo, ale jen diky tomu, ze je zajisteno, ze jakekoli vlakno precte z jakekoli mista v pameti bud nuly nebo data zapsana jinym vlaknem (coz je ochrana proti spatne synchronizovanemu kodu).
    Pokud tedy z nějakého důvodu nechci použít pozdní inicializaci implementovanou už v JVM, které nevytvoří instanci třídního objektu dřív, než je ta třída někde potřeba.
    Samozrejme se bavime o znacne teoreticke moznosti, ze takovy duvod existuje :-)

    Jak tak o tom premyslim, uvaha o poradi prirazeni reference a vykonani konstruktoru asi nema smysl. Melo by se uvazovat na zaklade happens-before a synchronizes-with vztahu. Pokud prirazujete do final nebo volatile promennych, pak muzete pocitat s tim, ze zadne vlakno neuvidi neuplne vytvoreny objekt. V ostatnich pripadech by mela byt snaha, aby v programu neexistovaly "data races", takze nejbezpecnejsi je explicitni synchronizace cteni i zapisu.
    Heureux qui, comme Ulysse, a fait un beau voyage.
    12.5.2007 01:46 Andrei Badea | skóre: 5 | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Nedalo mi a zeptal jsem se v mailing listu k Java memory modelu. Jeremy Manson odpovedel (viz archiv), ze double-checked locking nefunguje a basta. Pripada mi tedy nepravdepodobne, ze je zarucena uplna konstrukce objektu pred prirazenim do reference.

    Jeste k reseni s AtomicBoolean: pokud se misto AtomicBoolean pouzije volatile boolean priznak, pak tam data race nebude. Vyplyva to z JMM FAQ:
    Anything that was visible to thread A when it writes to volatile field f becomes visible to thread B when it reads f.
    To same by mohlo platit i pro AtomicBoolean, nevim to ale jiste.
    Heureux qui, comme Ulysse, a fait un beau voyage.
    12.5.2007 10:21 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Chápal jsme to tak, že reference na nový objekt je vrácena až po plné inicializaci v Javě odjakživa (tedy že to není novinka Javy 5), ale že před verzí 5 mohl nastat problém ve změně pořadí instrukcí. Ale máte pravdu, že to nestačí. Změnu pořadí instrukcí nemusí udělat jenom JIT, ale může k ní dojít až v procesoru, navíc lokální kopii paměti může mít opět i procesor, a v té dokumentaci není nic o tom, že by tomuhle JVM bránila. Takže explicitní synchronizace asi není ani od Javy 5 pouze sázka na jistotu, ale nutnost.

    Řešení s volatile se mi osobně moc nelíbí. Mám pocit, že volatile má sloužit především k označení proměnné, která může být měněna i jinak, než kódem, který má plně pod kontrolou JVM. Synchronizace je pak jen nutnou podmínkou, aby JVM s takovou proměnnou mohlo pracovat, ale není to hlavním účelem volatile (i když rozšíření významu volatile, ke kterému došlo v Javě 5, jde hodně směrem k synchronizaci). A protože je volatile vlastně implicitní synchronizace, může podle mne v některých výjimečných případech nastat situace, že bude „zamčeno“ zbytečně velké množství objektů a provádění se bude zbytečně řadit za sebe, místo aby běželo paralelně. Proto radši použiju explicitní synchronizaci a uzamknu přesně jen to minimum, které skutečně uzamknout musím.

    AtomicBoolean jsem navrhoval proto, že v některých případech nemusí být konstrukce objektu dokončena ani po té, co proběhly všechny konstruktory (typické je to u IoC v případě, kdy se závislosti nepředávají konstruktoru, ale nastavují se pomocí setterů). Pak už je opravdu jediná možnost mít nějaký „externí“ příznak určující, zda již objekt byl nebo nebyl inicializován. (Samozřejmě vedle toho je pak ještě nutný zámek na konstrukci objektu, aby nevzniknul vícekrát – AtomicBoolean používám jenom jako příznak bránící používání částečně zkonstruovaného objketu.)
    12.5.2007 17:37 Andrei Badea | skóre: 5 | Praha
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Mám pocit, že volatile má sloužit především k označení proměnné, která může být měněna i jinak, než kódem, který má plně pod kontrolou JVM.
    Tato definice odpovida spise vyznamu volatile v jazyku C. V Jave je volatile hlavne urceno pro komunikaci mezi vlakny jako nahrada synchronizace a bylo tomu tak uz uz pred Javou 5. Ma hlavne zajistit, ze zadne vlakno neuvidi "starou" hodnotu promenne v dusledku kesovani nebo preusporadani instrukci. Take zajistuje atomicitu zapisu a cteni 64bitovych promennych.

    Mate pravdu, ze memory model v Jave 5 zprisnuje semantiku volatile tak, ze to ma blize k synchronizaci (zapis volatile promenne ma stejny ucinek jako uvolneni zamku, atd.). Jenze toto zprisneni se IMHO tyka pouze pametove viditelnosti (memory visibility). Neni myslim spravne pohlizet na volatile jako na implicitni synchronizaci, nezpusobuje totiz zamykani objektu. Resi se spise instrukcemi pro pametove bariery tam, kde jsou potreba. Napriklad v prezentaci memory modelu Jeremy Manson tvrdi, ze na architekture x86 nema cteni volatile zadny overhead oproti cteni "bezne" promenne. O tom, ze volatile je levnejsi nez synchronizace svedci i preskrtnuty text a veta za nim v casti JMM FAQ o double-checked lockingu.
    Heureux qui, comme Ulysse, a fait un beau voyage.
    12.5.2007 18:25 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Úvaha o rozdílech mezi Javou a C++
    Tato definice odpovida spise vyznamu volatile v jazyku C.
    Ano, při psaní jsem si to uvědomil a poněkud jsem tím názorem na volatile sám sebe překvapil, protože jsem v C vlastně nikdy nic pořádného nepsal. Takže ještě k úvaze o rozdílech Javy a C++ – některé návyky z C/C++ si můžete do Javy přinést, aniž byste v C/C++ napsali víc než pár řádků ;-)

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.