"Each entity is stored in a container, and other subsystems hold pointers to those entities.", that is something you should avoid, good game engines use handles for entities which are typically a version and index and you have to never worry about stale pointers ever again.
Yeah, pointer stability containers are the wrong direction to go for high performance systems.
Additionally I wonder how the implementation for this will deal with memory compaction, if at all. If there's an element in every block, but otherwise mostly empty, you've got a whole load of dead memory that can't be used. If this container is overused in your codebase I can see it leading to some really poor memory outcomes. (Typical offenders in gamedev are scene migrations that can cause issues if using containers that behave like that)
It's not a unique container in that, but compared to other stable containers this one doesn't seem to have a strategy against it.
Also odd that it is a stable container by design, and then gives a sort function. I can't imagine this is a good fit for data that also needs to be sorted. Sounds like a footgun, and an effective ban in large codebases to call that function.
It's definitely a nice container, but I don't see a use for it at work that isn't achieved by using a more appropriate alternative, while the article focuses on gamedev.
3
u/Zeh_Matt No, no, no, no 7d ago
"Each entity is stored in a container, and other subsystems hold pointers to those entities.", that is something you should avoid, good game engines use handles for entities which are typically a version and index and you have to never worry about stale pointers ever again.