The C++ standard for the F-35 Fighter Jet [video]

Original Article ↗ Hacker News Discussion ↗

JSF C++ Subset & Determinism

  • Thread centers on the F‑35 C++ rules: no exceptions, no recursion, and no dynamic allocation after initialization (especially not in inner loops).
  • Many note this is standard for hard real‑time and embedded systems: you must prove worst‑case timing, avoid fragmentation, and eliminate hidden blocking (e.g., allocator mutexes).
  • Aim is determinism: fixed stack bounds, static memory, predictable control flow.

Memory, RAII, STL & Exceptions

  • Debate over RAII: some equate it with heap use (e.g., std::vector), others stress RAII is about lifetime, not allocation; can be used with static/stack memory and pools.
  • With -fno-exceptions, large parts of the standard library are awkward but not entirely unusable: containers can still be used if you accept terminate on throw, or follow the “freestanding” subset.
  • Others stress that in such environments you typically avoid std containers/strings anyway, often using custom allocators, pools, or shared-memory/paged containers.

Recursion, Control Flow & Timing

  • Recursion is banned because stack usage must be statically bounded and analyzable; explicit loops with fixed limits are easier to reason about.
  • Discussion of tail calls and potential Rust “tail recursion” operators that would be compile‑time‑verified, but not available in C++.
  • Some argue early returns and exceptions complicate reasoning about cleanup; others say early returns often reduce complexity and that exceptions can be fast if designed correctly.

Coding Standards (MISRA, JSF, AUTOSAR) – Help or Hindrance?

  • JSF rules compared to MISRA and AUTOSAR; all seen as part of DO‑178C–style process rigor rather than guarantees of correctness.
  • Supporters: static analysis plus strict rules reduce certain defect classes and aid auditability.
  • Critics: many rules are cosmetic or counterproductive (e.g., no early returns, weird unused-variable idioms), and empirical studies show some MISRA rules correlate with more defects.
  • Consensus: standards must be tailored; “blind 100% compliance with no deviations” is viewed as a misunderstanding.

Autocode vs Hand‑Written Safety‑Critical Code

  • Split views on Simulink/Matlab autocode:
    • Pro: eliminates common human slip‑ups (off‑by‑one, missed checks), gives high‑fidelity implementations of validated models; for many control problems pass/fail vs tests is what matters.
    • Con: output can be “spaghetti”, resource‑heavy, and hard to reason about; when autocode is later hand‑modified, guarantees vanish and complexity explodes.
  • Disagreement over whether extra CPU/RAM to accommodate bloated autocode is acceptable or can force more complex system architectures.

Stacks, Heaps & Mission Assurance (Satellites, Avionics)

  • Some claim satellites/avionics avoid STL and dynamic memory to keep variables at fixed addresses, so bad cells can be patched around and ground debugging can use exact replicas.
  • Others with space‑flight experience push back: stack use is ubiquitous; heap is often allowed at init; some modern missions use full C++ STL (e.g., std::map) with exceptions.
  • General pattern: static allocation for core control loops, possibly bounded pools elsewhere; heap usage is constrained but not universally banned.

Alternative Languages: Ada, Rust, C(+), GLib

  • Ada comes up repeatedly as the “obvious” safety‑critical choice; history explained: Ada was mandated, then dropped partly over ecosystem/tooling and hiring issues.
  • Some argue DoD should have enforced Ada harder; others point to high‑profile Ada failures (e.g., Ariane 5) as proof language alone doesn’t guarantee safety.
  • Rust is suggested as allowing “100% of the language” under similar constraints; rebuttal notes that std/alloc and panics conflict with MISRA‑style rules; real safety profiles would restrict Rust too (e.g., no_std, no third‑party crates).
  • One long subthread describes how GLib uses compiler cleanup attributes to emulate RAII in C: g_autofree/g_autoptr/g_auto plus type‑specific cleanup functions achieve destructor‑like behavior without full C++.

Other Domains: Games, HFT, Web Backends

  • Game engines commonly ban exceptions, RTTI, dynamic allocation in hot paths, and sometimes smart pointers; practices resemble JSF constraints.
  • HFT traditionally avoided exceptions for latency, though there are niche designs using exceptions to avoid branches on rare error paths.
  • Some web and infrastructure developers also avoid post‑startup allocations for performance predictability, using custom allocators and pools.

Error Handling: Exceptions vs Error Codes

  • In safety‑critical systems, error codes (or result types) are favored: clearer control flow, easier static reasoning, and fewer unwinding concerns.
  • Others note research showing exceptions can outperform carefully checked error codes in complex scenarios, but the main objection is semantic: unwinding is hard to make robust in low‑level code.
  • Thread acknowledges that both exceptions and error codes can be mishandled; discipline and tooling matter more than mechanism.

F‑35 Program Quality & Ethics

  • Mixed views on F‑35 overall: widely criticized for cost and schedule overruns, but also widely described as the most capable fighter currently in mass production and heavily exported.
  • Some see its software process as a relative success amidst hardware/management issues; others question focusing on refining tools for systems that can be used in ethically troubling ways.
  • Ethical objections to discussing its software “like any other tech” are raised; counter‑arguments frame technology as neutral and place responsibility on policy rather than code.