How to avoid downcasting in entity component system c++ - c++

Question

I recently came across the Entity Component System that is frequently used in game engines. I decided to implement it myself in C++, but quickly ran into a familiar problem. It all began innocent enough. I started with the following classes:
class Entity
{
private:
int entityId;
std::map<std::string, Component*> components;
public:
Entity();
~Entity();
void AddComponent(Component *component);
void RemoveComponent(std::string name);
bool HasComponent(std::string name);
Component* GetComponent(std::string name);
};
class Component
{
public:
int componentId;
};
I then decided to create some specific component types:
class Input : public Component
{
public:
void process();
}
class Physics : public Component
{
public:
void update();
}
I began to test this out. I created an entity:
Entity *entity = new Entity();
entity->AddComponent(new Input());
entity->AddComponent(new Physics());
This is where things started going wrong though. I then thought about how I would get components from an entity. What if I wanted to do something like:
Physics *physics = entity->GetComponent("Physics");
physics->update();
But GetComponent("Physics") returns the base class Component, not the derived class Physics! I did some searching on the internet but couldn't find an example in c++ that showed how to get around this problem. After taking a look at what Unity does, I discovered that they seem to just perform a down cast. For example in Unity the code (C#) would be:
Physics physics = entity.GetComponent("Physics") as Physics;
Isn't this down cast bad? How does one get around this in C++ when designing an Entity Component System? Or how does one perform the downcast?

Answer 1

The components that make up an entity are keyed on their type. If an ECS makes you write entity.get("Foo") as Foo then that's already a design weakness; it should make you write entity.get<Foo>().
In C++, you could write the code like this:
class Entity {
std::unordered_map<std::type_index, std::unique_ptr<Component>> components;
public:
template <typename C>
void AddComponent(std::unique_ptr<C> p) {
// can't remember if unique_ptr allows this conversion
components[typeid(C)] = std::move(p);
}
template <typename C>
C& GetComponent() {
// You *know* this cast has to work. You should handle null here though.
return *static_cast<C*>(components[typeid(C)].get());
}
};
Though note that it is rather unusual for an entity to hold its components at all. Usually you have a world, and it holds all components. An entity merely keys into the world's collection of components.
When your world has all components, then you can give it one collection per component type. (Indeed, that is a favored representation, since it often gives you better memory access patterns.) Then you don't need an abstract base class for your components anymore.

Answer 2

ECS revolves around casting and duck typing. But you can use a dynamic_cast for safety if you want (possibly just for debug builds), and hide it from the client so that you get this type of syntax:
Physics* physics = entity->get<Physics>();
And you got more safety than I do! Mine is implemented in C and provided through a C API to be used through plugins and scripts, so I have to actually cast from void pointers (but just in one central place).
It tends to not be a big deal in practice since the client code tends to ensure the integrity of what's going on since they're expressing the component type they want to retrieve. In C++ you can even do static checks at compile-time to make sure they are retrieving an actual component type and not some other type. I wouldn't recommend having them specify strings as you have though, since then a typo wouldn't lead to any type of compile-time error.
COM as used in DirectX also revolves around these casts to retrieve an interface. When it's unified through an interface query as in COM or a component query as in ECS, then it tends to not be a big deal in practice (people don't trip up over it as with a codebase that downcasts things sporadically with deep inheritance hierarchies).
A lot of the traditional practices revolving around OOP don't necessarily apply to ECS since it's such a radically different way of approaching architectures. For example, established OOP practices tend to strongly encourage information hiding, discourage downcasts, and SOLID suggests that dependencies flow towards abstractions.
Well, in an ECS, we have downcasts to retrieve components (but it's unified), we have components just exposing their data in raw form (but not a big deal since only a few systems access this data, so the scope of the data is narrow), and dependencies flow towards data, not abstractions (but somehow the design is much easier to keep stable anyway in at least game or game-like domains due to its enormous flexibility).
Or how does one perform the downcast?
One way is to store the key used to fetch the component as part of the component type, like:
struct Physics
{
enum {id = ...};
};
Then you can do like:
template <class Component>
Component* Entity::get()
{
const int id = Component::id;
// Find for the component from the id.
return component_ptr;
}
... or as Sebastian Redl points out, you can just use typeid (I forgot how to do this all statically due to that C API, since I have scripters and plugins adding new component types on the fly).