Vlákno názorů ke článku Entity Component System v C++20 od Baloun - Pěkná práce. Jen pár poznámek/otázek. Proč vlastně to omezení...
-
Pěkná práce. Jen pár poznámek/otázek.- Proč vlastně to omezení na C++20?
- U Operace group vidím dvojtou negaci "Toto není netriviální operace, ...".
- U všech Data Oriented Design technik to často stojí a padá s kontejnerem, tak mě zajímá váš názor na využití hive z C++26. Ne ani tak pro ECS, ale obecně.
-
Na první bych reagoval takto: https://en.cppreference.com/w/cpp/compiler_support/23.html
- je tam prostě příliš mnoho červených míst i u clangu a gcc, a navíc na některých strojích mám ještě pořád gcc-13. Update asi přijde s novou LTS distribucí (nejspíš ubuntu). Takže je to praktický důvod. U jednoho zákazníka, pro kterého programuji dlouhodobě je aktuálně schváleno gcc-10.3.
A to je C++23. Nevím v jakém stavu schvalování je C++26. Ale support je ještě tristní: https://en.cppreference.com/w/cpp/compiler_support/26.html- je tam víc chyb, postupně to opravím :)
Co se týče hive - musel jsem se podívat, jak přesně funguje - nejsem si jist, ale možná pokud bych zavedl archetypy, kde bych kombinace komponent přesouval do separátních poolů, pak by to asi šlo nějak použít.
Já tam aktuálně používám pro mazání strategii swap-and-truncate, tedy neděje se přesun všech prvků, jen jednoho. Ano, naruší to pořadí, ale zase to není velký issue. Výhodou je, že počet prvků zjistím tak, že odečtu end od begin, což se hodí, když se hledá pool s nejmenší mohutností. Pak je ještě výhoda v iteraci, že iterátor je vlastně random_access nebo aspoň bidirectional. To umožňuje range pro all_of<C> (enumerace entit dané komponenty) procházet náhodným přístupem. Oproti tomu samotný pohled (view<C>) už je input iterátor právě kvůli přeskakování. Jestli jsem pochopil hive taky přeskakuje, takže by se tam iterace maličko zesložitila.
Hive ovšem neřeší lookup, takže pořád potřebuji index. Index obsahuje pozice všech prvků - k tomu se právě hodí random access iterátor. -
U hive je zaručeno zachování raw ukazatelů na jednotlivé platné objekty. Udržuje se myslím seznam vektorů a pamatuje nějak prázdná místa při mazání. Nové přidávané vektory se s roustoucím počtem objektů zvětšují až na nějaké maximum. Sekvenční přístup je přes seznam vektorů, takže je to v zásadě cache friendly. I tak úplně nevím jak bych to využil, a tak různě sonduju. Ostatně dostalo se to do standardu, tak to musí mít nějaký důvod.
-
tak určitě to smysl má. Hodně mi to připomíná alokátor malých objektů od Andrei Alexandrescu, není to tedy poprvé co bych něco takového viděl. Tedy jestli to dobře chápu. Tohle si určitě uplatnění najde.
PS: zajištění validace pointerů to mě pravda nenapadlo. Já si tam ukládám offsety, protože pointery u vektoru zaručené nejsou, to je fakt. Jinak pokud něco takového potřebuju dnes, tak používám deque s tím, že si v položce dávám nějaký bit, který označuje, zda je pozice obsazena nebo není. Lifetime lze řídi v constexpr přes union {}
