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

9.5.2007 19:09 | Přečteno: 8000× | 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ší“.

• Instanciace. V Javě je posvátná. Smí ji vykonávat jen operátor new. Vždy se dynamicky alokuje paměť na haldě. V C++ běžně a často existuje instanciace mimo haldu a konstruktory i destruktory mohou být spouštěny z mnoha důvodů — konverze, předání parametru, vyhodnocení operátoru... Velmi zajímavým důvodem však je konstrukce a destrukce při kompozici. Kompozice v C++ nefunguje jen s použitím pointerů či referencí, ale většinou je výhodné přímé vkládání vnořených členů. (To Java umí jen u základních datových typů.) Při přímém vložení se samozřejmě kompilátor postará o správnou instanciaci každé položky, zatímco paměť je alokována najednou pro všechny položky společně.

• Volání metod. Pozor, v Javě se vždy chová „virtuálně“. V C++ nikoliv. Tam musí být u předka kouzelné klíčové slovo virtual. To způsobí, že takto označená metoda se stane součástí mechanismu virtuálních metod u všech potomků tohoto předka, a to i přes několik generací. V zájmu přehlednosti kódu je dobré (avšak nikoliv nutné) psát označení virtual i v kódu potomků. Je důležité si uvědomit, že metody bez označení virtual s mechanismem virtuálních metod nespolupracují a volaná metoda je pak pevně určena typem pointeru, přes který se volá.

• Destruktory. Ty jsou zase posvátné v C++. Narozdíl od finalizérů v Javě musí vždy správně dealokovat případné použité prostředky. Třída s virtuálními metodami musí mít virtuální destruktor, neboť... To je na dlouhé povídání. Velmi jednoduše řečeno: Uvolňuji-li instanci pomocí pointeru na předka, pak se nevirtuální destruktor bude pokoušet uvolnit paměť jiné velikosti, než by se uvolnit měla, což vede ve šťastném případě k odletu a v méně šťastném případě k memory leakage. Obě varianty jsem zažil a ani jedna není příjemná. Proto je lepší dávat pozor.

• Odlišné chápání pojmu reference. V C++ do ní nelze přiřadit. Přesněji řečeno, přiřazení reference do reference přiřadí pouze hodnotu referencovaného objektu, nikoliv referenci samotnou. Reference existuje v těsné vazbě s objektem, na který ukazuje. Ve výrazech se chová stejně jako referencovaný typ, zatímco při předávání parametrů se chytře chová jako pointer. Není určena k tomu, aby měla hodnotu null a aby fungovala jako reference v Javě. K takovým účelům jsou pointery. Ve skutečnosti je to ještě trochu složitější...

• Přetěžování operátorů. V Javě je přetížen jediný operátor, a to '+' pro Stringy. Programátor však zatím (bohužel či naštěstí — věc názoru) nemá k mechanismu přetěžování v Javě přístup. V C++ lze přetížit prakticky všechny operátory, což je na první pohled vidět například u vstupních a výstupních proudů. Má to samozřejmě i celou škálu dalších využití. Když jsem kdysi dělal knihovnu pro neomezenou aritmetiku, přetížil jsem snad úplně všechno.

• Odlišné chápání generických typů. Rozdílů mezi Templates a Generics je spousta, tedy jen několik hlavních: Instance Generics jsou analyzovány až za běhu a jsou součástí zkompilované třídy. Instance šablon v C++ vznikají během překladu způsobem, který je v podstatě ekvivalentní textovému preprocessingu. Vzhledem ke způsobu chápání datových typů v C++ je možné jako parametr šablony použít i typy, které v Javě patří mezi základní, tj. int a podobné. (To u Generics z pochopitelných důvodů nejde.) Dokonce může být parametrem šablony i jiný typ než třída, tj. například číslo. Existuje nepřeberné množství možností parciálních specializací jak celých tříd, tak i jednotlivých metod. Specializace funguje v C++ i v Javě podobným, avšak odlišným způsobem. V Javě navíc existují typové wildcardy, tj. konstruce typu T extends Type, T super Type. Tím je zajištěna dokonalá typová kontrola i při použití Generics. V C++, aspoň pokud vím, podobný mechanismus neexistuje. Nicméně setkal jsem se s parametry šablon tvaru T*, které předepisují, že příslušný typ musí být pointer. Už dlouho jsem však takovou konstrukci nepoužil.

• Odlišné chápání kontejnerů. Rozdíl mezi Collections a STL kontejnery je též velmi podstatný. Collections v Javě obsahují pouze a výhradně reference. Jelikož pro C++ je každý datový typ téměř rovnocenný (až na mnohé výjimky, ale na ty tu není prostor...), fungují STL kontejnery tak, že si každou novou položku okopírují. Každý typ použitelný pro instanciaci šablony kontejneru tedy musí mít copy-constructor a žádný kontejner neskladuje pouze reference. (Samozřejmě je skladovat může, ale jde mi o to, že například vector< int* > ukládá opravdu ukazatele na int, nikoliv reference na ukazatele na int.) Každá třída i každý „nestrukturovaný“ datový typ v C++ samozřejmě má svůj implicitní copy-constructor. Ten však vytváří pouze mělkou kopii. Proto není od věci buď používat při kompozici místo pointerů přímé vnoření, kde jen to jde, nebo vždy překrýt copy-constructor jiným, který dělá hluboké kopie. (Ale to už je spíš věc názoru.) Rozdílně je chápán i pojem iterátoru, viz dokumentace. Správný destruktor je u C++ často nejpodstatnější ze všech metod, protože šetří psychické zdraví programátora. Při použití kontejnerů a opakovaném vkládání objektů to platí dvojnásob. Kontejnery v C++ se ve velké většině případů vytvářejí přímo na zásobníku. Jejich obsah je samozřejmě ukládán na haldě, ale tím si nemusí programátor lámat hlavu, neboť vše vyřeší kompilátor společně s destruktory.

• Práce s pamětí. V případě C++ je dobré i pětkrát zopakovat, že je potřeba důsledně dbát na destruktory. Je nezbytné si udržet přehled o veškeré paměti na haldě, zejména pak o hlubokých a mělkých kopiích. Jinak se snadno a rychle uvolní používaná paměť, popřípadě se některé instance uvolní dvakrát, což vede k rychlému odletu. Zato však máte veškerou manipulaci s pamětí ve svých rukou, což může být vhodné zejména tam, kde se žádá maximální efektivita. Silným prostředkem C++ je pointerová aritmetika, kterou Java nemá, neboť poskytuje velmi vysoký stupeň abstrakce. Máte třeba pole o 64 prvcích. 64 je osm na druhou, čtyři na třetí nebo dvě na šestou. Chytrou deklarací proměnných typu pole v C++ můžete takové pole procházet všemi myslitelnými způsoby. Věřte, že to není zbytečné. Třeba když programujete Sudoku... Pointerová aritmetika šetří neustálé počítání offsetů, ale na oplátku zase nikdo nekontroluje meze.

• Synchronizace a komunikace. Programy v C++ nemají na virtuálním stroji ustláno. Proto je síťová komunikace, komunikace mezi procesy nebo synchronizace vláken mírně obtížnější než v Javě. V mnoha případech je potřeba znát mechanismy dostupné na konkrétním operačním systému. Bloky synchronized jsou v Javě velmi snadno použitelné. V případě C++ je občas nutné si přečíst dokumentaci k unixovému API pro dosažení téhož. Nelze však říct, že by takové počtení bylo na škodu. Jiný účel, jiné prostředky.

• Pojem rozhraní (interface) a jeho použití. Tento pojem je v Javě i v C++ chápán jinak. Interface není pro C++ ničím jiným než pojmem z knih o Design Patterns. Jde zkrátka o třídu, která slouží k vyjádření určitého souboru schopností potomků, které ji zdědí. Protože existuje vícenásobná dědičnost, není z pohledu kompilátoru důvod odlišovat například interface od abstraktní třídy. V Javě je naopak obojí důsledně rozlišováno, neboť vícenásobná dědičnost není dovolena — alespoň ne ve formě, kterou umožňuje C++.

• Pojem abstraktní třídy. V Javě musí být abstraktní každá třída, která obsahuje alespoň jednu abstraktní metodu. Protože je v Javě dědičnost vždy virtuální, není třeba další komentář. U C++ je situace složitější. Abstraktní třída nemusí být v záhlaví nijak označena. Vyznačuje se pouze tím, že má alespoň jednu tzv. čistě virtuální metodu. Ta je označena velmi ošklivou konstrukcí prototyp = 0;. Důvod je prostý. Zatímco v Javě musí být tělo metody (existuje-li) vždy u záhlaví, v C++ může být zapsáno odděleně a často bývá i v jiném souboru. Proto v C++ nestačí pouhé ukončení záhlaví středníkem, zejména vzhledem k nepřítomnosti klíčového slova abstract.

• Jeden z největších rozdílů — enum. Zatímco v C++ jde o jakýsi shluk názvů, které se navenek chovají jako celočíselné hodnoty, v Javě je sémantika mnohem složitější. Tam jde o syntaktický cukr, který vytváří shluk tříd dědících od společného předka. Jejich možnosti jsou ve srovnání s běžnými třídami omezené, ale ve srovnání s C++ ohromné. Mohou mít konstruktor a každá položka může mít svá data. Mohou implementovat rozhraní a tím s dokonalou názorností vystihují poučku „každý switch je zanedbaná šance na polymorfismus“. Kromě rozhraní může mít každý enum navíc i vlastní abstraktní metody, implementované všemi členy. Všude tam, kde se pracuje jen s jednoduchými a statickými daty a „skutečný“ polymorfismus by byl „buben na zajíce“, dokonale poslouží enum.

• Vícenásobná a virtuální dědičnost. Tento problém v Javě zdánlivě neexistuje, přesto však na něj člověk může narazit, neboť rozhraní mohou obsahovat statická data. V případě konfliktu názvů dvou konstant ve dvou různých rozhraních pak může docházet k potížím. Nic horšího se ovšem stát nemůže a i tento příklad je krajně nepravděpodobný. V C++ musí být ošetřen problém, kdy třída dědí od několika rodičů, z nichž někteří mají společné předky. To zajišťuje mechanismus virtuální dědičnosti, díky němuž kompilátor při kompilaci místo opakovaného vkládání dat předků vygeneruje jen pointery mířící na jednu společnou instanci společného předka. Tím se odstraní některé nejasnosti a logické rozpory plynoucí z existence společných předků. Velmi zajímavá je též nutnost přičtení offsetu při přiřazení pointeru na potomka do pointeru na předka. V případě jednoduché dědičnosti tento problém odpadá. U vícenásobné dědičnosti jej vyřeší kompilátor, aniž by o tom programátor musel vědět.

• Pohled na přístupová práva. V C++ neexistují balíčky, tudíž ani oprávnění typu default, zvané někdy „package private“. 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ý. Nesmíme však zapomenout na to, že u Javy nelze překrytím metody zpřísnit její přístupová práva. C++ toto umožňuje. Navíc má ještě mechanismus kombinující přístupová práva s dědičností, který určuje zacházení s daty předků umístěnými v potomkovi z pohledu vnějšího světa. Syntaxe dědičnosti a přístupových práv se v obou jazycích liší, ale jde většinou o kosmetické rozdíly. Důležitější je pochopit mírné rozdíly v sémantice.

• Základní priority jazyka. Java: Přenositelnost, přenositelnost, přenositelnost, odolnost vůči chybám programátora, maximální abstrakce hardwarových prostředků. C++: Efektivita, efektivita, efektivita, maximální volnost pro (zkušeného) programátora, maximální využití všech možností hardware.

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.

       

Komentáře

[Michal Vyskočil]

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.

[Andrej]

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]

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

[Andrej]

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;
}

[Andrej]

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

[Dusan]

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

[Andrej]

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

[Dusan]

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.

[ext3fs]

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

[Dusan]

no jasně že si chci pokecat, konečně někdo na úrovni

[happy barney]

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

[Andrej]

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.

[happy barney]

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

[Andrej]

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.

[happy barney]

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

[Andrej]

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

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.

[Andrej]

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.

[Kyosuke]

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

[Andrej]

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.

[Kyosuke]

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ší." 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".

[Filip Jirsák]

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ší." 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]

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.

[xmas_spirit]

imho java nema s c++ spolocnu ani tu latinku... tie dva jazyky spajaju tak maximalne bodkociarky a kucerave zatvorky :)

[Andrej]

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

[Andrej]

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

[xmas_spirit]

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

[Filip Jirsák]

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

[xmas_spirit]

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!

[Michal Vyskočil]

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.

[Michal Vyskočil]

Mělo tam být ... navíc se domnívám, že

[xmas_spirit]

nie nieje! ak v jave deserializujes objekt, ziadny konstruktor sa nezavola!!! a objekt je na svete...

[Filip Jirsák]

To máte pravdu, na to jsem zapomněl. Resp. onu klasickou serializaci dle java.io.Serializable jsem nikdy nepotřeboval

[Michal Vyskočil]

Jenže ona nám tu zůstává otázka, jak asi vznikla ta úplně první instance, kterou jsme potom serializovali?

[happy barney]

Deserializovať sa dá aj z dierneho štítku, serializácia mohla prebehnúť manuálne

[Michal Vyskočil]

No dobře, tuto možnost jsem skutečně nevzal v potaz

[Filip Jirsák]

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.

[xmas_spirit]

co su: "všechny požadavky na virtuální metody"?? staci linka na zoznam

[happy barney]

jednoducho povedané, struct je ako class s default public.

[Andrej]

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.

[happy barney]

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)

[happy barney]

pre upresnenie: tie použitia, kde finalobmedzuje dedičnosť.

[xmas_spirit]

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

[Andrej]

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.

[xmas_spirit]

ok, dik za doplnenie... ps: za clone za tiez neskryva ziaden new ;)

[Miloslav Ponkrá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.

[Andrej]

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

[Filip Jirsák]

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]

Jo a pak ty programy podle toho vypadají.

[Filip Jirsák]

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.

[xmas_spirit]

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

[Filip Jirsák]

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

[xmas_spirit]

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

[Filip Jirsák]

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

[Andrei Badea]

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.

[Filip Jirsák]

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.

[Andrei Badea]

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.

[Andrei Badea]

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.

[Filip Jirsák]

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

[Andrei Badea]

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.

[Filip Jirsák]

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ů