Separation of Concerns at Zero Cost: Modular Physics in C++20

Good software design means separation of concerns. A spring shouldn't know how a mass stores its position. An energy calculator shouldn't care which integrator you use. These principles are easy to state but hard to achieve in performance-critical C++—until now.

This talk demonstrates a component architecture for ODE systems where each piece has a single responsibility, communicates through typed interfaces, and compiles to the same machine code as a hand-written monolith. Just clean, testable, maintainable code.

Our running example: a coupled oscillator built from four separate components.

MassA and MassB: each owns its position and velocity, knows nothing about the other Spring: queries positions, provides forces—doesn't store state EnergyMonitor: computes system totals from component data These components compile together but develop independently. The spring doesn't include the mass header. The energy monitor doesn't know there's a spring. Yet the integrated system conserves energy to machine precision.

We'll walk through:

How typed state function tags replace manual wiring of inheritance hierarchies. Why C++20 concepts make this pattern practical What the compiler actually generates. How the same architecture scales to real vehicle dynamics and control systems These patterns emerged from years of developing production flight software. The coupled oscillator is a teaching example, but the architecture runs in actual guidance systems—where both correctness and performance are non-negotiable.

The goal isn't to show off template tricks. It's to show that prioritizing code quality—readability, testability, separation of concerns—doesn't require sacrificing performance. Modern C++ finally lets us have both. According to the authors knowledge it is a simple pattern that is not visible in the public code bases.