C and C++ ECS comparison

SIECS and Flecs for C and C++.

Both projects use archetype storage and provide C and C++ APIs. This comparison focuses on the SIECS language boundary, query model, application features, and integration path.

SIECS uses one model across C and C++

SIECS organizes entities by component set and processes component data in archetype tables. Its C API and typed C++ interface access the same worlds, queries, systems, relations, and metadata.

That shared model matters when an engine, module, or native tool crosses the language boundary: storage and scheduling do not change with the API.

Compare the language boundary

Area SIECS Flecs
C API Direct world, query, and iterator API Portable C99 API
C++ API Typed wrapper over the same C runtime Modern C++17 API over the Flecs runtime
Runtime ownership World owns storage, queries, systems, events, and metadata World owns entities, storage, queries, systems, and addons

In the SIECS C++ interface, callback references express read and write access. The underlying query still resolves the same tables and batches as the C iterator.

Archetype storage and query iteration

In SIECS, one exact component set identifies a table and each data component occupies a contiguous column. Persistent queries retain their compatible table set and expose one batch at a time.

Flecs also uses archetype and structure-of-arrays storage. Both models are best evaluated with the component shapes and system access patterns of the target application.

Schedule and inspect the same world

SIECS includes systems and phases, resources, observers, custom events, relations, hierarchy, inheritance, modules, reflection, JSON support, and an optional REST explorer.

Systems process queried data, observers respond to changes, and reflection exposes component schemas. The REST explorer reads those schemas and live entities from the running world.

Add SIECS as two files

The standalone distribution contains siecs.h and siecs.c. Compile the source as C, then include the public header from either C or C++.

Evaluate the complete workload

  1. Define the component sets and query access used by the application.
  2. Measure repeated iteration and composition changes separately.
  3. Build each runtime with the same compiler and optimization policy.
  4. Include relations, systems, reflection, and tools in the evaluation.
  5. Publish the source, machine, and compiler configuration with results.