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

📝 Discussion Summary (Click to expand)

The Hacker News discussion, stemming from a list of C++ constraints often seen in safety-critical or high-performance codebases, revolves around three primary themes:

1. Strict Memory Management (No Heap Allocation After Bootstrap)

A central theme is the prohibition on dynamic memory allocation (malloc/free or new/delete) after the initial program startup. This is driven by the need for deterministic timing and avoiding fragmentation, often cited in contexts like games, high-scale data infrastructure, and avionics.

Supporting Quote: "It is common practice to do no memory allocation after bootstrap." — jandrewrogers
Supporting Quote: "0 allocations after the program initializes." — WD-42
Supporting Quote: "And they take an unpredictable amount of time. That's very bad if you're trying to prove that you satisfy the worst-case timing requirement." — AnimalMuppet

2. Avoiding Exceptions for Determinism and Simplicity

There is a strong consensus, particularly among those working in domains requiring rigorous verification (like aerospace or game engines), that C++ exceptions should be disabled or banned entirely. The rationale is that exceptions introduce non-local control flow that complicates static analysis and WCET (Worst-Case Execution Time) verification.

Supporting Quote: "No exceptions" — mwkaufma (The initial constraint)
Supporting Quote: "Google style bans them: [link]" — tonfa
Supporting Quote: "In avionics, anything that can hide allocations, add unpredictable control flow, or complicate WCET analysis gets removed." — kaluga

3. Restrictions on Recursion

The constraint against recursion is motivated by the absolute necessity for statically verifiable stack usage, meaning the maximum stack depth must be calculable before the program runs, independent of runtime input.

Supporting Quote: "no recursion" — mwkaufma (The initial constraint)
Supporting Quote: "Per requirements, the stack capacity has to be statically verifiable, and not dependent on runtime input." — mwkaufma (Clarifying the rationale)

🚀 Project Ideas

Zero-Allocation RAII Resource Tracker Service

Summary

A service/tool that analyzes C++ codebases to guarantee that RAII objects (like file handles, mutexes, pool allocators) acquired within specific high-performance code sections (marked regions, or functions known to be in the inner loop) do not internally trigger heap allocations, adhering to the user requirement of "no malloc()/free() in the inner-loop."
Core value proposition: Provide deterministic assurance for performance-critical code segments regarding memory allocation behavior of standard and custom RAII wrappers, helping users satisfy strict static requirements (like those in aerospace/gaming) without dropping standard library features entirely.

Details

Key	Value
Target Audience	C++ developers in game engine, aerospace, HFT, or embedded systems needing static memory allocation guarantees.
Core Feature	Static analysis tool that traces constructor/destructor calls for RAII types within user-defined boundaries (e.g., function bodies or source files compiled with specific pragmas) and reports any reliance on dynamic memory allocation (directly or via standard library components like `std::string` or `std::vector` if used non-statically).
Tech Stack	C++ Frontend (e.g., Clang LibTooling/MLIR) for AST traversal, data flow analysis for tracking heap usage patterns, Web UI for reporting.
Difficulty	High (Deep data flow analysis across complex C++ templates/macros is tricky.)
Monetization	Hobby

Notes

Directly addresses the concern about standard library components (std::vector, std::string) potentially allocating memory even when used via RAII: "std::vector allocated and freed on the stack will allocate an array for its int’s on the heap…". This tool would check if that heap allocation path is taken in the traced scope.
Users are clearly looking for tools to police static constraints: "static memory allocation, no exceptions, no recursion." This offers a tool to enforce one of the trickiest constraints.
Potential for discussion on compiler vs. external analysis trade-offs.

C++ Idiom Compliance Linter (The "C+ Standard")

Project Title

C++ Idiom Compliance Linter (The "C+ Standard")

Summary

A configurable static analysis linter plug-in designed specifically to enforce "C with Classes" or highly restricted subsets of modern C++ (like the JSF C++ standard), as developers mentioned sticking to "C++ features that are really ergonomic... references, operator overloading" while avoiding others.
Core value proposition: Standardize and automate linting for highly constrained, efficient C++ subsets ("C+"), moving beyond generic style guides to enforce critical safety/performance rules (like no RTTI, no dynamic allocation, specific template usage rules).

Details

Key	Value
Target Audience	Developers working in industries like AAA gaming ("Unreal Engine compile without exceptions") or high-reliability embedded systems who want the safety of classes without the baggage of full modern C++.
Core Feature	A set of highly opinionated, pre-configured checker profiles (e.g., "GameDev Lite," "DO-178 Compliance") executed via Clang/GCC hooks, capable of enforcing rules like no default constructed standard library containers, no virtual functions, and no dynamic memory access.
Tech Stack	Clang-Tidy or customized ESLint/Prettier backend, integrated with CI/CD pipelines.
Difficulty	Medium (Relying on existing checker infrastructure like Clang-Tidy simplifies core implementation, but defining the target "C+" profiles is complex.)
Monetization	Hobby

Notes

Directly addresses the idea put forth by billforsternz: "A lot of people... write C++ but it's basically C plus a small set of really ergonomic and useful C++ features... This should be standardised as a new language called C+." This tool formalizes that definition into a checkable standard.
It would appeal to those who ban large parts of the STL/language features due to reliability or performance concerns.

Tail Recursion Verification Tool (TRV)

Project Title

Tail Recursion Verification Tool (TRV)

Summary

A compiler-integrated tool extension or static analyzer that specifically validates a function's recursive calls meet the criteria for guaranteed tail call optimization (TCO), explicitly supporting the proposed Rust-style become semantic for C++.
Core value proposition: Allow developers to write expressive recursive logic while satisfying the hard requirement of "no recursion" (which often means no stack overflow risk) by ensuring the compiler can safely rewrite the recursion into iteration (TCO), or explicitly flagging the function if TCO isn't possible due to local variable lifecycle issues (like the mention of std::vector drops).

Details

Key	Value
Target Audience	Developers constrained by requirements for statically verifiable stack usage, especially those who find manual iteration rewrites tedious or error-prone (e.g., those dealing with complex tree/graph traversals).
Core Feature	Analyzes recursive functions to determine if they are eligible for TCO. If a potential TCO exists, it checks for cleanup (Drop/Destructor) operations on local variables that would invalidate the TCO replacement, mirroring the proposed Rust `become` logic (early destructor invocation or compilation failure).
Tech Stack	LLVM/Clang IR analysis (to check for patterns that map to tail calls), combined with specific user annotations (e.g., `[[tco_eligible]]`).
Difficulty	High (Analyzing control flow and associated resource destructors across complex C++ code is extremely difficult.)
Monetization	Hobby

Notes

Addresses the specific pain point raised by tialaramex regarding the difficulty of enforcing "no recursion" while desiring the expressiveness of recursion, especially when dealing with destructors: "Rust's Drop mechanism throws a small spanner into this..."
This would solve the "stack capacity has to be statically verifiable" problem mentioned by mwkaufma, by proving the stack depth is bounded to one frame regardless of input depth.