C++ coding standards in 2026 -- MISRA, SEI CERT, JSF AV side by side, plus reflection-driven composable rule bundles

A regulated C++ project picks a coding standard. MISRA C++:2023 for automotive (ISO 26262). SEI CERT C++ for avionics + defense defensive coding. JSF AV C++ for older fixed-wing avionics (DO-178C). Pick one, run the matching clang-tidy check set in CI, maintain an exception log, ship. Then someone says “we also need to satisfy CERT for the audit cycle” and the analyzer-config matrix appears — two checker passes, two suppression lists, two ways for them to disagree on the same line of code. This page is the 2026 disambiguation table + a reflection-driven pattern that makes multi-standard projects a single static_assert.

Today

The three standards side by side

All three are C++ subsets framed as “do not do these things”. The differences are in coverage philosophy: MISRA is exhaustive and largely mechanical (covering ISO/IEC C++17); CERT is defensive and pattern-driven (anti-CWE focus); JSF is conservative and predates modern C++ (last revision 2020, still cited in fixed-wing).

MISRA C++:2023 superseded AUTOSAR C++14

A common point of confusion: MISRA C++:2023 is the live standard for automotive C++; AUTOSAR C++14 is retired. In 2023 the MISRA working group adopted AUTOSAR’s rules wholesale and re-published as MISRA C++:2023. Adaptive AUTOSAR now cites MISRA directly. Many tool vendors still expose an “AUTOSAR C++14” check-set name for backwards compatibility — treat it as an alias and cite MISRA in new safety cases.

Tool support today

The multi-standard problem

When a single header is consumed by two projects under different standards (a sensor-fusion library used in both an automotive ECU and an avionics flight-controller), CI runs both analyzer passes. The rules overlap (both ban raw goto, both demand non-public data) but they disagree on edge cases (MISRA allows certain reinterpret_cast patterns CERT forbids; JSF requires comment headers neither other standard demands). Each disagreement is a per-team allowlist; allowlists drift; audits surface the drift.

The next section closes the gap by encoding each rule as a consteval predicate over T’s reflection. Multiple standards compose with operator&&; a single static_assert(standards::all<T>()) applies the bundle.

Reflection today

Encode each coding-standard rule as a consteval predicate over nonstatic_data_members_of(^^T). Compose with &&. Multi-standard projects become a single static_assert.

namespace standards {

// MISRA C++:2023 Rule 11.0.1 -- non-POD class data members must be private.
template <typename T>
consteval bool meets_misra_11_0_1();

// SEI CERT C++ DCL56-CPP -- approximated as no raw pointer members
// (raw pointers are the highest-frequency vector for static-init-order
// issues; a faithful check would need call-graph analysis).
template <typename T>
consteval bool meets_cert_dcl56_cpp();

// JSF AV C++ Rule 75 -- no bit-field members (layout is implementation-
// defined; ABI breaks across qualified compilers).
template <typename T>
consteval bool meets_jsf_av_75();

template <typename T>
consteval bool all() {
    return meets_misra_11_0_1<T>()
        && meets_cert_dcl56_cpp<T>()
        && meets_jsf_av_75<T>();
}

}  // namespace standards

// Apply to a header consumed by an automotive + avionics project:
class SensorReading {
    double  value_;
    long    timestamp_;
    bool    valid_;
public: /* accessors */
};

static_assert(standards::all<SensorReading>());   // PASS

Add a public data member, MISRA fires; add a raw pointer field, CERT fires; add a bit-field, JSF fires. The diagnostic names the failing rule:

MISRA C++:2023 Rule 11.0.1: non-POD class data members must be private.
CERT C++ DCL56-CPP (approximation): no raw pointer members. Use std::unique_ptr...
JSF AV C++ Rule 75: no bit-field members. Bit-field layout is implementation-defined...

The composition pattern is the contribution; the three rules in the demo are illustrative. A real bundle would have dozens. The pattern composes with the hardened-stdlib schema lint, the qualified-compilers MISRA Rule 11.0.1 lint, the lifetime-safety borrow lint, the SoA layout transform, and the supply-chain SBOM walker — one walker, six predicates, every rule orthogonal.

Full source: posts/toolset/cpp-coding-standards/examples/reflect-coding-standard-bundle.cpp .

Reproduce locally

docker run --rm -it \
  -v "$PWD":/work -w /work \
  ghcr.io/wrocpp/cpp-reflection:2026-05 \
  bash -c 'clang++ -std=c++26 -freflection-latest -stdlib=libc++ -Wl,-rpath,/opt/p2996/clang/lib/aarch64-unknown-linux-gnu posts/toolset/cpp-coding-standards/examples/reflect-coding-standard-bundle.cpp -o /tmp/h && /tmp/h'

SensorReading passes the composed coding-standard bundle:
  MISRA C++:2023 Rule 11.0.1   (encapsulation)
  CERT C++ DCL56-CPP           (no raw pointers)
  JSF AV C++ Rule 75           (no bit-fields)

When NOT to use the reflection bundle

The pattern is brilliant for structural rules (data-member shape, type-level invariants) but cannot replace analyzers for:

• Cross-TU analysis (data-flow, taint propagation across translation units)
• Statement-level rules (no goto, no recursion in safety-critical code, MISRA’s “no preprocessor magic” rules)
• Style rules (naming conventions, indentation — those are clang-format’s job)
• Standards that mandate documentation comments (you need a custom plugin for that)

The reflection bundle complements analyzers; it does not replace them. The split is: the bundle catches the structural rules at compile time (cheap, immediate); the analyzer catches the rest in CI (expensive, eventual). Multi-standard projects benefit most because the analyzer-config matrix shrinks.

Where this is heading

C++29 candidate features collapse the loop further:

Profile enforcement (P3081 Sutter / P3589 Dos Reis / P3984 Stroustrup) lets a translation unit declare its standard as a compiler-enforced subset:

// C++29 candidate -- pseudo-syntax. As of 2026-05-15 not in any
// shipping toolchain. P3081/P3589/P3984 papers in WG21.
[[ profiles::enforce(misra_2023, cert_cpp) ]]
namespace sensor_fusion {
    // Inside this namespace: every MISRA + CERT structural rule is
    // compiler-enforced. The analyzer-config matrix shrinks to "rules
    // the compiler does not enforce yet."
}

Token injection (P3294, C++29 candidate) extends the pattern to inject standards-required boilerplate (audit-comment headers, traceability tags, allowlist-suppression markers) at the declaration site:

// C++29 candidate -- pseudo-syntax. P3294 in WG21.
[[ inject(misra_2023_audit_header, asil_b_traceability) ]]
class SensorReading { ... };
// Auto-injects: MISRA-mandated documentation header,
// auto-injects: ISO 26262 Part 6 §7 traceability tag,
// auto-injects: hashed link to the safety-case fragment.

The 2026 story is reflection-driven rule composition for structural rules + clang-tidy for the rest. C++29 collapses both into language-level enforcement plus compiler-injected boilerplate.

Cross-links: the qualified-compilers entry covers the vendor matrix (which compiler ships qualified for which standard) and includes the same MISRA Rule 11.0.1 lint as a stand-alone example. The hardened-stdlib, lifetime-safety-2026, simd-in-cpp-2026, and cpp-supply-chain-2026 entries show the same composable-walker pattern applied to other axes.

Reviewed: 2026-05-15. Composition pattern verified inside cpp-reflection container; rule selection illustrative (a real bundle would have dozens). Quarterly refresh.