Hlavní navigace

Názor ke článku Nerozumím... od ondra.novacisko.cz - @7 Pane Ponkrác. Programuju 2 desetiletí a nemusíte...

  • 23. 11. 2011 22:34

    ondra.novacisko.cz (neregistrovaný) 2001:0:5ef5:----:----:----:----:----

    @7 Pane Ponkrác. Programuju 2 desetiletí a nemusíte mě to učit. Znám naprosto přesně, co se děje při dynamic_cast. I co se děje ve Visual Studio. Předem tvrdím, že nelze paušalizovat, že dynamic_cast je pomalý. Toto platí jen pro Microsoftí implementaci. Nadruhou stranu, není to tak hrozný.

    Dynamicky typované jazyky hledají funkce v hashovacích tabulkách, někteří prý dokonce ne (@8), pak to asi nějak čaruji. Co já vím, tak třeba python má prostě dictionary, což není nic jiného, než prostě asociativní pole, a teď neřeším, jak je implementované, ale v průměru nebude mít o nic lepší složitost než log N (N je počet funkcí na objektu). Velmi podobné to bude třeba u javascriptu. Existence metody "doesNotUnderstand" je tedy jen logické rozšíření tohoto dispatchingu.

    A teď si to vemte, že v dynamicky typovaném jazyce hledáte název funkce, ať už jde o textový řetězec nebo nějaký ID, GUID, whatever. A porovnejte to s hledáním rozhraní v C++ ať už jde o textový řetězec nebo nějaké ID, GUID, whatever, který toto rozhraní identifikuje. Najděte pět rozdílů!

    Já bych viděl jeden podstatný. A ten hraje do karet C++. Zatímco pokud zavolám na neznámém objektu nějakou metodu, bude se hledat. Pravděpodobně se bude hledat pokaždé co jí budete volat. Možná, že tam bude nějaká cache, která přístup zoptimalizuje, ale moc bych na to nesázel. No a v C++ si nejprve necháte vyhledat interface, a pak už vesele voláte metody na tom interface, aniž byste musel rozhraní a funkce znova a znova hledat.

    Virtuální funkce v C++ mají díky povinné deklaraci všeho jednu převratnou výhodu a to tu, že každá funkce může mít ID představující index do tabulky funkcí, takže není třeba již nic hledat, složitost je 1. Pouze složitost hledání rozhraní bude zhruba log N.

    Ovšem ne u Microsoft C++. Microsoft by samozřejmě mohl lépe organizovat RTTI data, mohly by vedle názvů tříd používat i 4bajtové hashe, hash tabulky, a podobně, možná by byl rychlejší, než to, jak to dělá teď ... projíždí obyčejné pole a každou položku vyhodnocuje porovnáváním řetězců. Otázkou je, o kolik procent by se to zrychlilo celkově. Nicméně zhlediska jazyka, nic lepšího než dynamic_cast nemáme, a ani vlastně nepotřebujeme. K dynamickému typování naprosto dostačuje.

    @9 no ono se to nedá spustit ani s těmi hlavičkovými soubory. Je to plné deklarací. Interface se musí podědit nějakou třídou. Příklady vám teď tady dávat nebudu, nemám na to čas. Časem možná dofinalizuju celou knihovnu (LightSpeed) a dám jí někam na download. Postoval jsem to pro ty, kteří umí číst v C++ zdrojáku. Jsou tam dvě zajímavé metody getIfc a proxyInterface.