CASTLE 2.0 ships header-only C++17 templates for safety-critical embedded targets

The developer behind CASTLE has published a prototype version 2.0 of the library, a header-only C++17 template toolkit aimed at safety-critical embedded systems. According to the announcement on dev.to, CASTLE — short for Compliant Automotive Safety Template Library for Embedded — is intended to stand in for parts of the C++ standard library and larger application frameworks on automotive ECUs, microcontrollers and other targets where memory, timing and allocation behavior are tightly constrained.

What CASTLE offers

The dev.to post describes CASTLE as a lightweight, header-only library that works with C++17 and earlier language levels. The author cites the Embedded Template Library (ETL) as inspiration and states the project's goal plainly: make everyday C++ jobs easier on small targets without the runtime costs that often come along. Version 2.0 continues work that began with a CASTLE 1.0 announcement on the same platform.

The constraints it is built around

The release highlights a set of constraints that mirror practice in automotive and other safety-critical domains:

• Deterministic, fixed-capacity behavior where practical
• Heap allocation is not required
• RTTI is not required
• Exceptions are not required
• Core data structures avoid virtual functions
• No dependency on the C++ standard library

Each point targets a familiar pain point in embedded work. Dynamic allocation introduces nondeterministic timing and fragmentation risk, which is why it is commonly ruled out in production embedded and automotive code; fixed-capacity containers instead hold their memory up front. Skipping exceptions and RTTI trims runtime machinery and binary size, and matters on platforms where those features are disabled. Keeping virtual functions out of the core data structures removes vtable indirection and hidden dynamic dispatch, which can complicate worst-case timing analysis. Dropping the STL dependency means the library remains usable on toolchains and build configurations where parts of the standard library are unavailable.

On toolchain support, the announcement lists GCC, Clang and the ARM compiler families as targets. The author also names firmware and device development as natural fits for the library, though the published post cuts off at that point, so the full list of intended use cases is not visible.

Prototype status and caveats

The release is explicitly labelled a prototype version 2.0. The announcement makes no claim of conformance to a specific safety standard, certification or maturity level; the word "compliant" in the project's name signals its direction rather than a completed assessment. Teams considering it for regulated environments would need to run their own verification and qualification process, as they would with any third-party dependency. Interested readers can compare the 2.0 post against the earlier version 1.0 announcement to see how the API surface has evolved.

Why it matters

Embedded C++ developers have long faced a gap between what the standard library assumes and what safety-critical targets permit. Dynamic allocation, exceptions and RTTI are baked into much of the standard ecosystem, yet they clash with automotive development guidance and the realities of microcontrollers with very little RAM. Projects like ETL, and now CASTLE, try to close that gap by supplying familiar container and utility patterns with predictable, static behavior. A new entry in this space gives constrained-platform teams an alternative, and the header-only, STL-free design lowers the barrier to trying it out. The prototype label means it is early days, but the constraint list itself is a useful checklist of everything embedded C++ code typically has to live without.