Vlákno názorů k článku Rychle, rychleji až úplně nejrychleji s jazykem Go od ondra.novacisko.cz - Vše co má nový jazyk zvládat, tak zvládne...

Nepochopení zástánců GC je v tom, že každý objekt musí někomu patřit. Právě že v OOP struktuře je GC něco jako „Bůh“ a my ateisti na Boha nevěříme. Komu patří objekt, který už nikdo nehce? Bohu? Ten ať rozhodne o jeho osudu.

Jenže ateista ví, že žádný Bůh není a tak už primárně navrhuje strukturu tak, aby vlastník byl znám. Ten pak má na starost úklid objektů, jež již nejsou potřeba. Přitom ono „není potřeba“ nemusí být záležitost jen o analýze vzájemných odkazů. Může to být rozhodnutí dané okamžikem. Uživatel klikne na „Close Document“ a v ten okamžik vlastník objektů „dokument“ provede hromadný úklid, bez ohledu na to, kolik bylo v dokumentu kruhových referencí.

Ano, chápu, existují možnosti, že někdo úklidem odstraní objekty, které odkazuje někdo z vnějšku. Opět je to ale chyba struktury, protože tento pirátský odkaz by měl být oznámen vlastníkovi, ale nebyl a to je špatně. Existuje tu nějaká hierarchie, něco, co říká za co kdo zodpovídá. A proto většinou člověk GC nepotřebuje, protože program navrhuje už s ohledem na existenci hierarchie a tedy přirozených vlastníků a správců, což jak bylo správně uvedeno, jsou kontejnery, a jejich správci.

A kdyby náhodou to „nešlo nijak udělat“ stále si lze v 95% procentech pomoci čítačem referenci, a pokud je dobře udělanej, tak uživatel vůbec nepozná, že to tak funguje a pracuje s objekty jako v Javě.

A kdyby se náhodou někdo dostal k těm 5% procentům, tak o pár příspěvků níže jsem postnul 2 odkazy na C++ řešení GC, ale jak sami zjistíte, jedná se zase jen o nástroj, který pomáhá vlastníkovi … pastýři sehnat dohromady své ovečky a zajistit mezi nimi vztahy a zbavit se nepotřebných… Tedy je to jakási forma kontejneru obsahující nástroj na procházení zpětných odkazů pomocí technik hledání kostry grafu. Nic moc lowlevel, ale funguje to jako GC… ale zatím jsem to moc neupotřebil.

To by mne zajimalo, jak jste dosel k tomu, ze zastanci GC nechapou koncept vlastnika. Aspon ja to chapu velmi dobre. Ale pokud nemate ciste stromovou strukturu, tak musite mit mechanismus, jak vlastnikovi sdelit, ze jeho objekt odkazujete a naopak, ze jste odkaz zrusil.

No a problem nastava v okamziku, kdy nekdo tu (od)notifikaci napsat zapomene. Takova chyba se typicky projevuje nekdy uplne jindy a uplne jinde, nez kde k ni opravdu doslo a ladit to je peklo (a to casto i kdyz pouzijete nastroje pro toto urcene).

Pouziti GC setri spooooustu casu – jednak na psani kodu slouzici pro tu infrastrukturu vlastniku (pocitani odkazu, notifikace) a jednak na ladeni memory leaku. Samozrejme do realtime systemu bych GC nedaval (nebo aspon ne ten Javovy), ale to je zas jina kapitola :-)

„No a problem nastava v okamziku, kdy nekdo tu (od)notifikaci napsat zapomene.“

Sám víte, že tohle do OOP nepatří. K čemu jsou setři a getři. Aby vlastník (objekt) věděl, že mu někdo pod rukou mění stav nějakého jeho memberu. A tady máte analogii. Pokud mám správce něčeho … nějakého mraku objektů… nemohu s nimi pracovat jak chci… Musím neprve za správcem, aby mi dal oprávnění… v řeči programátora obdržím objekt, se kterým pak mohu do mraku vstupovat. Vstupenka je pro cizáka, a zároveň notifikace pro vlastníka, protože si eviduje vydané vstupenky.

Pokud už se dva správci domluví na zvláštnim vztahu… sdílení… pak nastupují počítané reference, se kterými často vystačíte…

„Pouziti GC setri spooooustu casu – jednak na psani kodu slouzici pro tu infrastrukturu vlastniku (pocitani odkazu, notifikace) a jednak na ladeni memory leaku“

Ano… možná bych GC uvítal v DEBUG režimu… ale oni naštěstí existují nastroje, které to umí bez GC :-) Třeba valgrind, nebo Visual Studio má nástroj na detekci memory leaku. Pokud ale budete pracovat čistě a nedělat prasárny, tak jej kolikrát ani nevyužijete. Naopak já jako programátor C++ mám s Javovským GC obrovské problémy, když adaptuju postupy v programování, kde hodně využívám sílu destruktorů, a kde nejsem schopen v Javě takový destruktor vynutit ani ručně (a když už to nějak obejdu, tak Javu degraduju na procedurální jazyk).

Zapomnel jste na tu odnotifikaci, tu zadnym standardnim OOP mechanismem automaticky neudelate. Navic delat odnotifikaci po kazdem getu objektu je… ehm… dost nepohodlne. Pokud mate single-thread aplikaci, muzete to obejit dvema variantami getteru – jednou s notifikaci a druhou bez, ale zase kdyz omylem pouzijete nespravnou…

Ano, nastroje jsou, taky jsem je pouzival… ale kdyz nad objektem provadite za dobu jeho zivota (nekolik hodin / dni) treba 1000 referenci / dereferenci a jednou zapomenete odreferencovat, tak tezko zjistite, ktera. A ne vsechny provozni problemy se daji vyvolat v kontrolovanem prostredi.

To neni jenom o cistote, ale taky o povaze problemu. Nektere problemy vyzaduji jednoduche pametove struktury, nektere slozite.

To by mne zajimalo co to je ta „sila destruktoru“ :-D Pokud na tom trvate, pseudo-destruktor je mozne si udelat i v Jave. Bude fungovat stejne jako v C++, akorat nebude realne uvolnovat pamet objektu.

" ale kdyz nad objektem provadite za dobu jeho zivota (nekolik hodin / dni) treba 1000 referenci / dereferenci a jednou zapomenete odreferencovat, tak tezko zjistite, ktera. A ne vsechny provozni problemy se daji vyvolat v kontrolovanem prostredi."

Mluvíte o C++? Znáte chytré ukazatele? Věděl byste, že tenhle případ vám s chytrým ukazatelem nenastane.

„To by mne zajimalo co to je ta „sila destruktoru“ :-D “

Takže nemluvíte o C++ ale o C. To byste se tak hloupě neptal. Síla v destruktoru je ta, že se destruktor provede v okamžik, kdy platnost objektu končí. Ne „až někdy“. Destruktoru právě používají třeba ty chytré pointery. Ale co třeba uzavírání resourců? A abych šel dál, mám třeba resource, třeba jako „externí soubor“. Funguje tak, že se normálně do něj zapisujete a při destrukci se uploaduje na server. Uživatel (programátor – uživatel knihovny) nepozná, že se jedná o „externí soubor“, pracuje s ním stejně, jako by byl lokální.

„Pokud na tom trvate, pseudo-destruktor je mozne si udelat i v Jave. Bude fungovat stejne jako v C++, akorat nebude realne uvolnovat pamet objektu.“

Nebude! Musíte je volat ručně! Já jsem se o něco takového pokoušel tady: http://bredy.novacisko.cz/?… … mno ale nic moc.

Destruktory jsou navíc pomalé, volají se pozdě. Viz článek.

Nojo, ja v C++ delal velmi malo, takze mi auto pointery unikly. Sikovna featurka, pravda. Tim se da pocitani referenci z velke casti automatizovat – akorat s cykly to ma trochu problem (mozna nekdo udelal auto ptr, ktery tohle resi(?)).

Ano, „destruktor“ se musi volat rucne, s auto ptr vam to C++ zavola samo, to je pravda. Na druhou stranu, jediny pripad co mne napada kdy na tom volani fakt zalezi je prave uvolnovani resources, to je v Jave / .C# to je trochu neelegantni (nutnost obalovat try – finally), ale nastesti ne prilis caste.

Takže abych to celé shrnul, není to o GC, ale o tom, že Java nemá mechanismus jak dát objektu vědět, že vypadnul z kontextu. Ten by principielně asi nebyl problém udělat, ale v Javě není a její autoři pro to asi mají dobré důvody. A jeden takový mně napadl:

Co když vypadává z kontextu více objektů a při implicitním volání destruktoru jednoho z nich dojde k vyjímce? Co dělat? Jsou tři možnosti:

1) Vyhodit vyjímku nahoru. To je špatně, protože nebudou zavolány destruktory dalších objektů a kód pro obsluhu vyjímky s tím nemůže nic udělat, protože ty objekty už nemá v kontextu.
2) Vyjímku ignorovat a volat destruktory dalších objektů. To je špatně, protože se nikdo o vyjímce nedozví.
3) Vyjímku „pozdržet“, zavolat destruktory dalších objektů a pak ji teprve poslat nahoru. Ale co když další destruktor vyhodí další vyjímku? Tak musíme jednu z nich skrýt a to je špatně.
4) Dá se představit řešení kdy by se vyjímka pozdržela, a pokud je vyjímek více, vytvořila by se nová „zapouzdřující“ vyjímka… ale to by bylo dost hnusné a krkolomné řešení.

Takže jak je vidět, to volání destruktoru na objekty vypadávající z kontextu je pěkné, ale má zásadní problém s handlováním vyjímek. BTW, jak tohle řeší C++?

Destruktor může hodit výjimku. Ačkoliv někteří programátoři důsledně odmítají výjimky v destruktorech a důsledně deklaruji destruktor s klíčovým slovem throw() — bez výjimek.

Nicméně, pokud destruktor vyhodí výjimku, přesto probíjá dál volání destruktorů předků a memberů. Destruktor, který vyhodil výjimku je považován za provedený.

V případě, že další problém nevznikne, výjimka je vyhozena až do nějakého catch handleru a ten jí zpracuje. Destrukce většinou probíhá hned, ne „až někdy“ u chytrého pointeru v destrukci toho pointeru. Takže příjemce výjimky je znám.

Pokud dojde k dvojité výjimce, tedy při zpracování destruktorů v důsledku výjimky, a tato výjimka není odchycena v tomtéž desruktoru v jehož těle (nebo v nějaké volané funkci) vznikla, program skončí na terminate(). Tohle je pravidlo. Protože prostě teď by letěly dvě výjimky a nebo by si musel program vybrat. Což je nepřípustné. Nicméně programátor má možnost tohle postihnout. Má k dispozici funkci std::uncaught_ex­ception() která vrací 1, pokud se provádí unwind z výjimky. V tom případě je program varován a může se zachovat podle toho.

Já to řeším tak, že prochází-li výjimka destruktorem, je to jako signal „rollback“, Pakliže s uzavřením resourců je spojena nějaká činnost, třeba upload dat, která může skončit výjimkou, tak se vynechá, protože rollback. Pokud nemohu takové činnosti zabránit, tak výjimku odchytnu a zahodím. Už jedna výjimka je in progress, další výjimka může být zavlečená, tedy vznikla v důsledku té první výjimky.

Tohle ještě rozšiřuji tak, že když letí výjimka z mé knihovny a má vyletět výjimka také patřící do mé knihovny, výjimka si zjistí, že jedna už letí a protože každá výjimka z mé knihovny má tzv. „reason“ (stejně jako v javě, tedy odkaz na další výjimku, která taky může mít reason), pak se tato výjimka přidá jako reason. Pokud už tam reason je, projde se řetěz a přidá se na konec řetězu.

„Takže abych to celé shrnul, není to o GC, ale o tom, že Java nemá mechanismus jak dát objektu vědět, že vypadnul z kontextu. Ten by principielně asi nebyl problém udělat, ale v Javě není a její autoři pro to asi mají dobré důvody. A jeden takový mně napadl:“

Ale jsou, finalizery. Ale jsou _P_O_M_A_L_E_ . Neprovádí se ihned, ale až si VM vzpomene. A běžně se stává, že si nevzpomene vůbec, nebo uvázne dřív, než si stačí vzpomenout. Zkuste v javě otevřít a zamknout soubor a ve finalizeru jej zamknout. Zkuste to teď udělat dvakrát. S tím, že mezitím vždy objekt opustíte, Jednou to projde, a podruhé skončíte deadlocku. Nenašel jsem žádný způsob, jak vyvolat finalizaci explicitně, aby se provedl předtím, než se pokusím soubor otevřít a zamknout podruhé.

Nejsou pomale, ale jsou neco jineho nez chcete – jsou volany pri GC a ne pri vypadnuti objektu z kontextu.

Ad reseni s vice vyjimkami: Aha, tak to je dalsi spatne reseni, ktere mne nenapadlo :-D Samozrejme destruktory vetsinou vyjimky nevraci (explicitni), ale mohou kdykoli vyhodit runtime vyjimku.

„Nejsou pomale, ale jsou neco jineho nez chcete – jsou volany pri GC a ne pri vypadnuti objektu z kontext“

Ano, tím označuji, že jsou pomalé, tedy že se nevolají hned, ale až někdy. Chybějící „pravé destruktory“, nikoliv finalizery právě způsobují, že javu moc nemusím :-D. Hlídání memory leaku tak člověk zaplatí něčím jiným. Možná, kdyby Java uměla explicitní destrukci objektu, nebo objekty, které nelze sdílet a jsou likvidovány při opuštění kontextu.

„Ad reseni s vice vyjimkami: Aha, tak to je dalsi spatne reseni, ktere mne nenapadlo :-D“

A které je správné? Zjistíte, že žádné. I to javovské je špatné.

„Samozrejme destruktory vetsinou vyjimky nevraci (explicitni)“

Výjimky se nevrací, výjimky se hážou. Výjimka má dvoje poslání. Přerušit probíhající operaci a informovat volajícího. U vyjimky v destruktou není co přerušovat, takže její význam je spíš informační.

C++0× bude umět řešit i tyhle typy výjímek,

1) C++ je kompromis mezi výkonem a čistotou. Valná většina metod nemusí být virtuální a tak je zbytečné věnovat výkon procesoru na virtualizaci metod. Prostě to něco stojí. Všichni nadáváme na pomalé počítače a sami si je ještě zpomalujeme

2) No, ono to tak není. Můžete volat virtuální metody, ale zavolají se jen na té úrovni, která je zkonstruována. Konstrukce objektu není jednorázová záležitost a tak volání virtuálních metody nezpůsobí zavolání její reimplementace v potomkovi, protože v době konstrukce ten potomek ještě není zkonstruován. Totéž platí pro destruktor. Virtuální metoda v destruktoru se nezavolá do již zdestruované části objektu.

Nadále odmítam diskutovat s lidma, který programování viděli z rychlíku a nazývají se programátory!

„POSÍLAJÍ ZPRÁVY“

S tím nemám problém

„aby VZDÁLENĚ PŘIPOMÍNALO posílání zpráv v OOP.“

Ano. přesněji, aby C++ bylo co nejvíc OOP a zároveň využilo co nejvíc výkonu procesoru. Od toho bodu na jednu stranu jsou jazyky co nejsou tak OOP a jsou rozhodně rychlejší než C++. Na druhou stranu jsou jazyky bližší OOP avšak jakákoliv další abstrakce stojí mnohonásobně výkonu. Já se domnívám, že to je příliš drahá cena. V C++ zvládnu spoustu OOP technik bez toho, aniž bych platil výkonem. A je v dannou chvíli jedno, jestli si objekty posílají zprávy, nebo volají metody. Nejzajímavější je to, že když si do C++ dopíšu určitý framework, udělám tam i objekty, které si opravdu budou posílat zprávy a nebudu potřebovat tříd a interfaců. Zatímco v C++ naprogramuju i čistý OOP framework, obávám se že v čistém OOP frameworku těžko naprogramuju C++.

„No a to je právě ono. Objekty v C++ nejsou objekty“

Ne, tady jste úplně vedle. Pokud se v OOP řeší dědičnost a to, že objekt se skládá z předka a je rozšířen o potomka, pak konstrukce takového objektu je prováděna nejprve konstrukcí předka a následně potomka. Předek ale nemůže volat potomka, když ten neexistuje. Tady jste se bohužel spletl, protože technicky opravdu není problém, aby konstruktor zavolal virtuální metodu potomka. Ale záměrně to neudělá, protože to je špatně. Je to chyba, a právě proto jsem byl naštván, protože to ukazuje hlubokou neznalost OOP. Věřte mi, že tohle záměrné omezení stojí při konstrukci objektu nějaký výkon, protože každý konstruktor musí reinicializovat vtabulku a konečný potomek ji pak ještě znova nechá přepsat podle sebe. Přitom by mohl vtabulku nastavit jednou před zahájením konstrukcí předků a bylo by to rychlejší a vyhovalo by to vašim požadavkům. Jenže by to bylo nepřijatelné chování.

Nadávám proto, že mnoho lidí si tu představuje programování jako znalci sportu, kteří veškerý sport znají ze sportovního kanálu. Všichni víme jak je C++ objektově zmršený jazyk a přitom nevíme nic o objektovém programování. Nakonec mě dorazí prohlášení, že OOP jazyk musí obsahovat garbage collector, což je přesně to, proč Javu ani C# nepovažuju o nic objektovější, než C++ a díky tomu, že člověk platí výkonem, tak jsou ještě horší. (GC se stará o paměť na úkor ostatním resourců, které je třeba spravovat ručně, tery neobjektově)

A vy jste přesně ten typ člověka, který ví, jak je to špatné, aniž by věděl, jak je to vlastně správně.

Nečetl jsem to celé, nebudu, nemám na to čas. Kočka se skládá ze savce a kočky. Nevím, proč se mne snažíte přesvědčit o opaku. Nemůžete naučit savce mňoukat, dokud se nevyvine v kočku.

Bavíte se o tom, co je objekt, a zapoměl jste na základní věc. Objekt musí vzniknout. OOP teorie vznik objektu nějak extra neřeší, zatímco C++ je praktické řešení této teorie. Zkuste v jiném objektovém jazyce donutit kočku mňoukat v době, kdy se snažíte vytvořit společné znaky všem savcům. Uvidíte že pohoříte.

Tečka.

Proxy objekt do OOP nepatří.

Proxy objekt samozřejmě můžete udělat i v C++. Stačí jen proxovat rozhraní, kterým bude objekt komunikovat. v C++0× se plánuje přidat pro tyhle případy zvláštní konstrukce, které proxy objekty budou tvořit podle vzoru automaticky.

Komunikace pomocí zpráv a pomocí interface se liší jen v jednom detailu. Zatímco objektu můžete poslat libovolnou zprávu, tak při použití interfacu pouze určujete jakýsi „komunikační protokol“, což je běžná věc v jakékoliv jiné komunikaci. Množství protokolů v C++ přitom není omezen a teoreticky můžete pro každou zprávu generovat samostatný protokol (interface). Objektu lze zaslat zprávu podle libovolného protokolu s tím, že pokud objekt protokol nepodporuje, tak komunikovat nebude. Stejně jako v OOP. Interface pouze jen z výhodou združuje zprávy patřící ke stejnému protokolu, čímž se samozřejmě šetří výkon, protože ověřování protokolu (hledání interface) samozřejmě opět stojí nějaký výkon navíc.

Stejně jako poslání zprávy… musí tu zprávu vyhledat v nějaké tabulce, rozparsovat parametry, případně identifikovat objekt zprávy… všechno stojí výkon.

C++ v zásadě umí vše, co by měl umět OOP jazyk. Jen někdy se člověk snaží ne úplně všechno použít, protože balancuje mezi výkonem a užitečností.

Naučte se C++.

Hezká hračka. Nic, co by se nedalo udělat v C++.

Je mi jedno, jestli jazyk běží nebo neběží nad virtuálním strojem, chci, aby to bylo rychle. btw. díky JIT a optimalizacím již příliš neplatí, že bytecode jazyky musí bejt pomalejší, pomalu se na čistě kompilovanej kód dotahujou a
někdy (díky možnostem optimalizace za běhu, které se nedají provést během kompilace) jsou i rychlejší.
A tendle trend bude pokračovat – stejně jako dřív byly šachy na počítači zoufale slabý, teď již sváděj souboje s velmistrama a pomalu nabývaj vrchu, stejně tak i neni daleko doba, kdy počítač udělá optimalizace kódu přinejmenším stejně dobře jako programátor. Ale to je vlastně trochu vedlejší věc, jen reaguju na to, že virtuální stroj je zloděj výkonu…

Fakt je, že snad všechny moderní jazyky včetně těch, které žádnej virtuální stroj nemají (např. i „blbej“ object pascal) zvládaj diamantovou dědičnost interfaců lépe a ve výsledku rychleji (nemusí řešit x-úrovňový virtuální dědičnosti) než C++. To prostě není záležitost virtuálního stroje, to je špatnou implementací vícenásobný dědičnosti v C++.
Např. nejjednodušší metoda jak to vyřešit by byla, kdyby kompilátor zopakoval ve VMT pro nově poděděný interface implementovaný metody z předků těch interface – klidně i volitelně nějakým klíčovým slovem.

Šablon jsem právě pro obejití tohodle využíval – ale to je s odpuštěním trochu prasečina. Teď už bych na to radši použil tu virtuální dědičnost, je to čistší.

A co se týče toho, že se to vhodnou strukturou dá obejít a že při návrhu počítám s diamantovym děděním – to je právě pointa mého předchozího příspěvku – že to je právě to, proč říkám, že C++ není příliš vhodný pro objektové programování. Protože mě nutí při návrhu jedné třídy modifikovat jiné třídy, ke kterým notabene ani nemusím mít přístup a nutí mě myslet na to, co by za mne mohl v pohodě udělat kompilátor (a co taky u ostatních jazyků kompilátor dělá).

„Např. nejjednodušší metoda jak to vyřešit by byla, kdyby kompilátor zopakoval ve VMT pro nově poděděný interface implementovaný metody z předků těch interface – klidně i volitelně nějakým klíčovým slovem.“

A že tam máte tu base 2× to vám je jedno, že? A co když do ty base date member proměnnou? Co potom? A co když jí tam nedáte vy, ale někdo, komu ta knihovna patří?

Programujte jako v Javě. Diamantovou dědičnost převeďte na volání delegátů a máte to.

„Jakou bází mám kde dvakrát? Myslíte tu část objektu definovanou v IA? Dvakrát nula je furt nula. Tadle „duplicita“ ničeho mě opravdu netrápí.“

Nabízím konzultace nebo výuku programování v C++, kontaktujte mne na adrese ondra.novacisko.cz.

V rámci sezení proberemi i technické informace o implementaci objektů v C++, i proč nevirtuální dědění znamená duplikace instancí,které většinou nejsou ku prospěchu věci. Probereme si i to, jak je implementováno virtuální dědění a kdy stojí výkon a kdy nikoliv.

Ceny nejsou vysoké.

> C++ má dost silný typový systém a přetypování v zásadě nepoužívám (myšleno klasické Cčkovské). Přetypováním nemyslím dynamic_cast a static_cast případně const_cast, protože se defacto nejedná o přetypování, ale pouze pomůcky řešící zejména implementační obtíže OOP adaptovaného přímo do efektivního kódu procesoru (žádný virtuální stroj).

Ale jedná se o přetypování. Například dynamic_cast často potřebujete proto, že v C++ není možné dělat kontravariantní změny v typech parametrů metod.

Další omezení C++ je, že podtřída je vždy zároveň i podtyp.

> Genetika C# a v Java je pouze kamufláš. Ve skutečnosti je to jen implicitní přetypování vycházející z předpokladu, že každý objekt je potomkem nějakého generického objektu.

Pro C# toto neplatí, tam se kód pro instance generik generuje za běhu programu JITem a ten dokáže také sdílet různé části kódu. Nemluvě o tom, jak pohodlně se takový program ladí.

> Pomocí šablon můžete i napsat kód, který se provede v době překladu. I když je trochu omezený, tak jeho síla je obrovská. Je to totiž deklarativní jazyk, něco jako PROLOG a kdo v něm umí chodit, zvládne v tom programovat tak, že překladač během jednoho běhu přeloží kód který si sám vygeneruje v rozsahu několika desítek tisíc řádků.

Tak Template Haskell je právě o tom, že kód běží na úrovni překladače, ale
s tím rozdílem, že je to plnohodnotný Haskell. Zato šablony v C++ jsou mnohem omezenější než celé C++. A s Prologem bych to až tolik nesrovnával, protože ten má backtracking.

> Template Haskell bych už zase neřadil do C++,

Nemyslel jsem zařadit Template Haskell do C++, ale udělat do C++ něco podobného tj. třeba možnost psát funkce v C++, které se budou vykonávat v době překladu a budou moci generovat kód.

> 2) Nemáte pravdu! Šablona se na venek tváří jako separátní kód a je to správně. Protože výsledný kód pro jednu třídu může být úplně jiný než pro jinou třídu.

To sice může, jenže často je téměř stejný (až na typy).

Na C# potřebujete virtuální stroj a framework. Tam se realizuje OOP lépe, protože každý objekt obsahuje runtime databazi metod. Proto nepotřebujete přetypovávat, protože pokud objekt nepodporuje metodu, nebude nalezena v tabulce a program skončí s výjimkou.

V C++ nic takového není… naštěstí nebo bohužel? V C++ je virtuální metoda realizována pomocí indexu v tabulce adres s přístupem se složitostí 1 (v C# log N). Nevirtuální metoda dokonce má složitost nulovou, protože je to jen skok na adresu (v obou případech procesor není přetížen flushováním front). Volání metody v C++ tak bude vždy rychlejší než v C#, i kdyby byl překladač JIT 1000× lepší, než GCC

dynamic_cast není přetypování, je to jen přechod předka na potomka. V žádném případě nedojde ke změne objektu, pořád se pracuje se stejným objektem, který po dynamic_castu umí to co uměl předek, z něhož se vycházelo. static_cast je stejný jako dynamic_cast, pouze se provádí při překladu, pokud je převod znám a autor programu převzal zodpovědnost za to, že referencí je skutečně objekt, který uvedl.

Všechno tohle je dáno tím, jak je C++ implementován. Je skoro zázrak, že C++ zvládne techniky OOP i přesto, že výsledkem je nativní kód bez nutosti podpory ze stran velkých frameworků a s tím, že valná většina OOP technik má přímou transformaci do nativního kódu.

„Nemyslel jsem zařadit Template Haskell do C++, ale udělat do C++ něco podobného tj. třeba možnost psát funkce v C++, které se budou vykonávat v době překladu a budou moci generovat kód.“

Současné C++ šablony umí vykonávat kód v době překladu. Není to tak přímočaré, ale kdo to umí, tak mu to nedělá problémy.

„A s Prologem bych to až tolik nesrovnával, protože ten má backtracking.“
Ale je tam, sic omezený. Nicméně pokud některou funkci nelze instanciovat pro syntaxtickou chybu v parametrech, tak překladač vybere jiného kandidáta. S PROLOGem má společný hlavně deklarativní zápis a způsob výběru pravidel včetně jejich specializací. Backtracking by se hodil, ale bez něho se taky obejdu. Prostě cesty které nevedou k výsledku zaříznu už na úrovni specializace, případně v místě rozhodování pošlu překladač do jiného pravidla.

„To sice může, jenže často je téměř stejný (až na typy)“
Vidím, že znáte C++ líp než ja :-D Haha.

> V C++ nic takového není… naštěstí nebo bohužel? V C++ je virtuální metoda realizována pomocí indexu v tabulce adres s přístupem se složitostí 1 (v C# log N). Nevirtuální metoda dokonce má složitost nulovou, protože je to jen skok na adresu (v obou případech procesor není přetížen flushováním front). Volání metody v C++ tak bude vždy rychlejší než v C#, i kdyby byl překladač JIT 1000× lepší, než GCC

To je nesmysl. C# to realizuje úplně stejně jako C++ (s výjimkou klíčového slova dynamic).

> dynamic_cast není přetypování, je to jen přechod předka na potomka.

A když ten potomek má jiný typ než předek, tak je to přetypování.

> V žádném případě nedojde ke změne objektu, pořád se pracuje se stejným objektem, který po dynamic_castu umí to co uměl předek, z něhož se vycházelo.

Přetypování je o změně typu a ne o změně objektu.

> Všechno tohle je dáno tím, jak je C++ implementován. Je skoro zázrak, že C++ zvládne techniky OOP i přesto, že výsledkem je nativní kód bez nutosti podpory ze stran velkých frameworků a s tím, že valná většina OOP technik má přímou transformaci do nativního kódu.

Nic moc zázračného na tom nevidím. Eiffel má silnější typový systém a překládá se do C.

„To je nesmysl. C# to realizuje úplně stejně jako C++ (s výjimkou klíčového slova dynamic).“

Nesmysl píšete Vy.

„A když ten potomek má jiný typ než předek, tak je to přetypování.“

Máte v tom chaos. Nemotejte dohromady typy, třídy a objekty. Typ je jen syntaxtická berlička. Podle tohoto pohledu se samozřejmě přetypovává i v Javě. Jedna věc je změna typu „ukazatele“ tedy změna pohledu na stejnou věc, druhá je změna věci jako celku. Přetypování z int na float je ten druhý případ a to není případ dynamic_castu.

„Nic moc zázračného na tom nevidím. Eiffel má silnější typový systém a překládá se do C.“

Otázkou je, zda existuje přímá transformace. Zkuste někdy analyzovat výstup Eiffelu, třeba tam najdete dosti hustý framework.

Nevím co máte s typovým systémem. z hlediska OOP jsou typy spíš přítěží než výhodou.

> Nesmysl píšete Vy.

Ve 4. odstavci je napsáno, že C# používá pro virtuální metody také vtable:

http://en.wikipedia.org/…method_table

> Máte v tom chaos. Nemotejte dohromady typy, třídy a objekty. Typ je jen syntaxtická berlička.

Já se obávám, že v tom máte zmatek Vy. Typ není žádná syntaktická berlička.

> Podle tohoto pohledu se samozřejmě přetypovává i v Javě.

Tvrdím snad, že ne? Problém ale je, že existuje řada případů, kde by se tomu dalo vyhnout, jenže kvůli omezenosti typového systému to nejde a musíte použít přetypování (ta omezenost se týká i Javy).

> Nevím co máte s typovým systémem. z hlediska OOP jsou typy spíš přítěží než výhodou.

Typy (ve staticky typovaných jazycích) mohou výrazně dopomoci ke správnosti programu a informace z typového systému může být využita kompilátorem při optimalizaci programu. To, že dnes nejpoužívanější OOP jazyky jsou dnes 20 let nebo ještě více pozadu za vědeckými poznatky ještě neznamená, že typy jsou přítěží.

„Já se obávám, že v tom máte zmatek Vy. Typ není žádná syntaktická berlička.“

Je. OOP nezná typ objektu. OOP zná jen objekt. Dokonce OOP nezná ani třídu. OOP je pouze o objektech, které přijímají zprávy. Typ slouží jen k tomu, aby překladač poznal dopředu, podle jakých pravidel se bude jednat.

Typ definuje protokol, interface, kanal, pohled (view), syntaxtická berlička. Přetypování, jak vy říkáte, je jen změna protokolu, interface, kanalu, pohledu. Normální akce, bez které se neobejdete. Vyplývá to z logiky věci. A to jestli překladač umí přetypovat automaticky, nebo se mu to musí říct ručně, to už je vedlejší.

Nevím, jak by vypadal svět s dokonalým typovým systémem. Zkuste nahodit příklad. Nechci žádný odkaz. Svými slovy.

> Nevím, jak by vypadal svět s dokonalým typovým systémem. Zkuste nahodit příklad. Nechci žádný odkaz. Svými slovy.

Správně typovaný program skončí (na konečném vstupu) a nedojde v něm k běhové chybě (pokud je dostatek paměti).

> Je. OOP nezná typ objektu. OOP zná jen objekt. Dokonce OOP nezná ani třídu. OOP je pouze o objektech, které přijímají zprávy. Typ slouží jen k tomu, aby překladač poznal dopředu, podle jakých pravidel se bude jednat.

Já si pod OOP představuji to, co je popsáno v knize „Foundations of Object-Oriented Languages: Types and Semantics“, kde jsou objekty, třídy a typy. Ale jsem si vědom toho, že někteří autoři neuznávají třídy, nicméně nevím, že by někdo neuznával typy – nedovedu si představit formalismus, který by neznal pojmy typ a podtyp – AFAIK běžně se to používá – už jen kvůli definici polymorfismu.

Ještě tu o Červené Karkulce. Nebo už vás nakazili ekologové a budete tvrdit, že nejlevnější energie je z přírodně obnovitelných zdrojů.

Předpokládám, že nějaké oficiální srovnání, nebo aspoň nějaký hmatatelný důkaz určitě nemáte.