Hlavní navigace

Názor ke článku Chytrý a chytřejší od Ondřej Novák - Jistě je to možné, ale některé konstrukce třeba...

  • 4. 11. 2011 0:16

    Ondřej Novák (neregistrovaný)

    Jistě je to možné, ale některé konstrukce třeba právě kontejnerů v STL znemožňují používat různé optimalizace, například děsivý alocator, ještě děsivější streamy (zkuste si je rozšířit), z principu nemožnost nebo dokonce zákaz používání stringů v režimu COW, či s čítačem referencí v režimu R/O. Spoustu věci je skryté, interní, a není zde možnost to změnit.

    Nerozumím větě "kde se jinak shared_ptr divoce kopíruje.". Co to znamená? On se tem váš chytrý ukazatel divoce nekopíruje? Pokud jsem z dosavadního popisu pochopil, tak ona ref class není nic jiného, než když bych já napsal class Něco: public RefCntObj (objekt s intruzivním počítáním referenci). Optimalizovat se tady moc dobře nedá. Divím se, že zrovna v podání C++/CX to má být rychlejší. Pokud vím, tak je to postaveno na COM+, kde metody AddRef a Release jsou virtuální, což znamená koukat do nějaké tabulky adres, která zrovna jako na podporu nemusí být v cache. Když použiju čistě šablonové řešení intuzivního čítače, vyšvihne překladač do kódu vlastní instrukce příčítání a odčítání jedničky s testem na nulu. Pokud navíc se čítač nachází u objektu, nemám zde nebezpečí výpadku stránky jako u CX. V případě shared_ptr z STL mám dokonce pocit, že tam hrozí dva výpadky stránky, protože čítač je jinde, než objekt, jelikož čítání není intruzivní. Tam bych viděl problém s rychlostí.

    A ještě jedna věc. Dodnes jsem nepochopil, proč se při pošoupávání prvků v kontejnerů v STL používají operátory přiřazení. Má to děsivý overhead.