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.
Autor se zabývá vývojem kompilátorů a knihoven pro objektově-orientované programovací jazyky.
Přečteno 35 404×
Přečteno 24 418×
Přečteno 23 160×
Přečteno 19 655×
Přečteno 16 904×