Imagine iterating a tree or accessing a hash table looking for a component instead of having a v-table that tells you where the component struct is in the entity.

Imagine this: What if all Renderable components were in a list, pointed to each other -- and maybe each Renderable component is allocated via a slab alloc so the list is cache coherent. And all components were like this.

Then each system starts processing the first component it knows about (head of list), and iterates across all entities with said components. The v-table is accessed to convert between entity pointer and component, so you can go from component->entity->otherComponent w/o a hash table or etc.

W/O custom allocator, it's useless to me. Hell, even in C my AVLTree implementation allows custom allocators for the node, you just set a AVLT.NodeFactory function pointer method on the AVLTree struct. By default nodes are allocated by malloc(), but a Node may be included inside a struct, and the Node just points to the top of the struct it is in via its Node.value property... so the allocator for this will just do some pointer math when you pass the value into the .NodeFactory, it can simply cast value to (myStruct*), then return the address of myStruct->Node property. Woo lookit me, this is the foundation of entity component systems, understand? The myStruct can be said to have a Node component. Where is my tree or hash table? It's just a v-table made of the type information C maintains itself.

Each to their own, but it sounds like your entity system is gonna be slow as mole-asses if you actually implemented it the way its described.