How do I contiguously store and iterate over ECS components in C++?

Entity component systems store data in one of three ways:

1. Centrally allocated arrays, accessable by all systems.
2. Contigious arrays of subsets of components that each system is interested in.
3. Contigious array of "entities" allocated in a centrally located memory buffer.

Naughty Dog uses scenario 1. An entity in this context is just a collection of numbers:

struct Entity { static const int FOO = 0; static const int BAR = 1; int components[MAX_COMPONENTS]; uint32_t id; }; 

The "components" in the above code are either "-1" meaning "no component of this type, or a positive number, zero inclusive. This is an index to a centrally stored array of each set of components:

class ComponentAllocator { public: FooComponent foo_components[MAX_FOO_COUNT]; BarComponent bar_components[MAX_BAR_COUNT]; }; 

Then any system can use some singleton/service locator pattern to get access to it, and iterate over it:

void FooBarSystem::update() { for (auto& entity: entities) //entities is just a collection of type Entity { Foo& foo = getComponentAllocator().foo_components[entity.components[FOO]]; Bar& bar = getComponentAllocator().bar_components[entity.components[BAR]]; // Do something that requires interaction between foo and bar. // ... } } 

In scenario 2, your entity is the storage for each set of components, and each system stores a collection of proxies to that entity.

class Entity { public: std::map<std::type_index, std::shared_ptr<IComponent>> m_Components; uint32_t id; // some helpful functions for adding and removing via templates. } 

Each system stores a "proxy" to the entity, but only has access to a subset of the components. The component is also a "subject", from the subject/observer pattern, which allows any change in the component to propogate to any interested proxy. Whilst this is a good way to do things, it carries a lot of boiler plate, and isn't good for the novice to learn.

Scenario 3 just allocates a byte array, which gets set with as many components as you need. This is also complex, but very good for embedded systems, such as mobile devices and consoles.

I have purposely left out in depth explanations on most of this stuff, as it would take too long to explain all three, so I recommend you look them up and figure out which is best for you.