Reference counting je povolený, ale navenek nesmí být vidět. To je hodně těžké udělat. Navíc s přibývajícími jádry není reference counting žádná výhra a pro krátké stringy je daleko rychlejší když je to krátké pole přímo uvnitř stringu.
že si z STL celkem konzistentně vybíráš věci, které se úplně nepovedly a ty povedené naopak ne.
No hádám, že jsi člověk z nějaké akademické půdy, který nikdy nic pořadnýho nenaprogamoval, ale jen tu obhajuje svojí víru. Zkus za použití pouze stl psát nějaký větší projekt, který by měl být rychlejší, než kdejaký skriptovací jazyk, nebo jazyk s překladem do bytecode, abys obhájil smysluplnost programování v C++? Velice záhi zjistíš, že ta milenka standardní knihovna je pěkná potvora a ještě k tomu líná.
Pro tvojí informaci, problém s reference countingem u řetězců není v tom, že by to bylo pomalé v moderních procesorech... Ono to pomale je, ale stejně to pomalé bude i bez reference countingu, protože to je obecný problém sdílení dat mezi jádry a jejich synchronizace. Ten problém je mnohem hlubší, už v základním návrhu. Já časem pochopil, proč je snaha zakazovat ref counting. Je to snaha dodefinovat návrh tak, aby odpovídal původnímu záměru a netrpěl problémy, který tomu časem zařídili jednotliví implementátoři.
Reference counting
nemá být skrytý. Naopak má být
viditelný. Programátor musí dostat do rukou nástoje , jak s tím pracovat. Základní problém
std::string je ten, že se má chovat jako vektor znaků dle definice. V tu chvíli nesmí být sdílený. Jakékoliv operace přidání znaku, změna znaku a podobně nutně vedou na vytvoření kopie, která interně získá jinou adresu (c_str() začne vracet něco jiného). naopak
std::string nemá rozhraní pro možnost kopii řetězce a pochopitelně nic neříká o tom, co se děje s řetězcem v MT prostředí. Všechny tyhle nedotaženosti vedou k tomu, že se to implementátoři snaží řešit obecně a detekovat všechny ty výše popsané situace, tak, aby se to chovalo jako pole znaků.
Pokud naopak řeknu, že řetězec je od
počátku otevřeně sdílený s reference countingem a zakážu přímý přístup k řetězci (jakmile jednou LightSpeed::String vznikne, je const a nedá se jeho obsah změnit, lze jedině vytvořit nový řetězec s upraveným obsahem), definuju jak se řetězec chová v MT prostředí (ref counting ve výchozím stavu není MT safe, takže se ty řetězce nesmí sdílet mezi vlákny, to je záměr) a dám k dispozici rozhraní pro možnost odstranit sdilení (metoda isolate() ) nebo vyrobení fyzické kopie (metoda copy() ), tak je to úplně něco jiného, co člověku přinese spoustu výhod a zabrání spoustu chybám a neočekávaným komplikacím, za předpokladu, že dodrží všechna pravidla s tím svázaná.
Já v té knihovně nemám jediný objekt na řetězce. Mám tam ConstStringT<T> - odkaz na libovolnou sekvenci znaků kdesi v paměti, StringPool<T> - kolekce řetězců vhodná pro řetězcové mapy, StringParam<T> - řetězec nebo reference podle použití, hodí se při vyhledávání v mapách (není třeba alokovat paměť, pokud chci najít určitý řetězec v mapě), samozřejmě AutoArray<T....> - což je stejné jako std::vector<T> nicméně tenhle objekt se dá převést na ConstStringT<T>. Z toho jsou odvozené objekty StaticString<T, n> a SmallString<T,n>, kde n udává maximální počet znaků. Alokuje se to pak přímo v tom objektu. Rozdíl mezi StaticString a SmallString je ten, že ten první má to n jako pevný limit, a při překročení háže výjimku. Ten druhý, SmallString, to číslo se chápe jako hint a při překročení to způsobí jen snížení výkonu, protože se musí alokovat na haldě.
Nic takového mi stl nenabízí. Jenom string
KRYTON: Aha. Přiblížit hlavu těsně... ehm, k předmětu. Dobře, chápu. A co další optické jevy: obrazová montáž, zpomalení, kvantel...
LISTER: Nic takovýho nemáme.
KRYTON: (Skepticky) Nemáte to, jenom zoom. (Komicky se naklání k seznamu) No, nic, to je dobré, to úplně stačí, opravdu výborné
Zobrazit příspěvky
