I wonder how these compare to high frequency training standards. It seems like they'd have similar speed/reliability/predictability requirements in the critical paths.
The “90% ban” isn’t about hating C++ — it’s about guaranteeing determinism. In avionics, anything that can hide allocations, add unpredictable control flow, or complicate WCET analysis gets removed. Once you operate under those constraints, every language shrinks to a tiny, fully-auditable subset anyway.
The same is true for the software that runs many satellites. Use of the STL is prohibited.
The main issue is mission assurance. Using the stack or the heap means your variables aren't always at the same memory address. This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.
You can definitely have local variables on the stack. I don't know where you got that you don't use the stack. Heap is kind of a no-no, although memory pools are used.
> If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.
You can and do put the stack and heap pool at fixed memory ranges, so you can always do this. I'm not sold at all with this reasoning.
For what it's worth, I am an active developer of space flight software. This might be true somewhere, but it's not true anywhere I've ever encountered. The contortions required to avoid using the stack would be insane and cause far more bugs than it could ever prevent. I'm pretty confident asserting that this is simply not a thing. Even heap allocation is very often allowed, but restricted to program initialization only. Furthermore, these rules are relaxing all the time. I am aware of at least one mission currently in space that is flying the C++14 STL with no restrictions on heap allocation and exceptions enabled. Unmodified `std::map` is currently flying in space with no ill effects.
https://web.archive.org/web/20111219004314/http://journal.th... (referenced, at least tangentially, in the video) is a piece from the engineering lead which does a great job discussing Why C++. The short summary is "they couldn't find enough people to write Ada, and even if they could, they also couldn't find enough Ada middleware and toolchain."
I actually think Ada would be an easier sell today than it was back then. It seems to me that the software field overall has become more open to a wider variety of languages and concepts, and knowing Ada wouldn't be perceived as widely as career pidgeonholing today. Plus, Ada is having a bit of a resurgence with stuff like NVidia picking SPARK.
I'm convinced this was a psyop actually, with the intent of delaying other country's 5th gen programs or development of quantum radars. It definitely had some cost overruns but I think its performance as a fighter is pretty impressive.
Criticism is fair however: they did probably extend themselves too far with the helmet technology, and I do have concerns about touch screens in cockpits (a touch screen requires you to take your eyes off of a target to move your hand to the right location, rather than locating a button by touch).
The F-35 program was a complete disaster, with enormous delays, cost overruns and very long lists of issues.
Right now it is also the single most advance combat airplane, built in any number, which exists anywhere in the world and guarantees that the USA will be able to convincingly assert air dominance in any conflict.
Her point about exceptions vs error codes was that one failed to catch exception of particular and and things went south meanwhile if we instead "catch" error code all will be nice and dandy. Well one might fail to handle error codes just as well.
That is of course not to say that exceptions and error codes are the same.
> All if, else if constructs will contain either a final else clause or a comment indicating why a final else clause is not necessary.
I actually do this as well, but in addition I log out a message like, "value was neither found nor not found. This should never happen."
This is incredibly useful for debugging. When code is running at scale, nonzero probability events happen all the time, and being able to immediately understand what happened - even if I don't understand why - has been very valuable to me.
The C++ standard for the F-35 fighter jet prohibits ninety percent of C++ features because what they are actually after is C with destructors. I was just thinking about how to write C in a modern way today and discovered GLib has an enormous about of useful C++ convieniences in plain C.
Reading through the JSF++ coding standards I see they ban exceptions, ban the standard template library, ban multiple inheritance, ban dynamic casts, and essentially strip C++ down to bare metal with one crucial feature remaining: automatic destructors through RAII. When a variable goes out of scope, cleanup happens. That is the entire value proposition they are extracting from C++, and it made me wonder if C could achieve the same thing without dragging along the C++ compiler and all its complexity.
GLib is a utility library that extends C with better string handling, data structures, and portable system abstractions, but buried within it is a remarkably elegant solution to automatic resource management that leverages a GCC and Clang extension called the cleanup attribute. This attribute allows you to tag a variable with a function that gets called automatically when that variable goes out of scope, which is essentially what C++ destructors do but without the overhead of classes and virtual tables.
The heart of GLib's memory management system starts with two simple macros: g_autofree and g_autoptr. The g_autofree macro is deceptively simple. You declare a pointer with this attribute and when the pointer goes out of scope, g_free is automatically called on it. No manual memory management, no remembering to free at every return path, no cleanup sections with goto statements. The pointer is freed whether you return normally, return early due to an error, or even if somehow the code takes an unexpected path. This alone eliminates the majority of memory leaks in typical C programs because most memory management is just malloc and free, or in GLib's case, g_malloc and g_free.
The g_autoptr macro is more sophisticated. While g_autofree works for simple pointers to memory, g_autoptr handles complex types that need custom cleanup functions. A file handle needs fclose, a database connection needs a close function, a custom structure might need multiple cleanup steps. The g_autoptr macro takes a type name and automatically calls the appropriate cleanup function registered for that type. This is where GLib shows its maturity because the library has already registered cleanup functions for all its own types. GError structures are freed correctly, GFile objects are unreferenced, GInputStream objects are closed and released. Everything just works.
Behind these macros is something called G_DEFINE_AUTOPTR_CLEANUP_FUNC, which is how you teach GLib about your own types. You write a cleanup function that knows how to properly destroy your structure, then you invoke this macro with your type name and cleanup function, and from that moment forward you can use g_autoptr with your type. The macro generates the necessary glue code that connects the cleanup attribute to your function, handling all the pointer indirection correctly. This is critical because the cleanup attribute passes a pointer to your variable, not the variable itself, which means for a pointer variable it passes a double pointer, and getting this wrong leads to crashes or memory corruption.
The third member of this is g_auto, which handles stack-allocated types. Some GLib types like GString are meant to live on the stack but still need cleanup. A GString internally allocates memory for its buffer even though the GString structure itself is on the stack. The g_auto macro ensures that when the structure goes out of scope, its cleanup function runs to free the internal allocations. Heap pointers, complex objects, and stack structures all get automatic cleanup.
What's interesting about this system is how it composes. You can have a function that opens a file, allocates several buffers, creates error objects, and builds complex data structures, and you can simply decl...
42 comments
[ 3.5 ms ] story [ 59.1 ms ] thread- no exceptions
- no recursion
- no malloc()/free() in the inner-loop
https://www.stroustrup.com/JSF-AV-rules.pdf
Actual code i have seen with my own eyes. (Not in F-35 code)
Its a way to avoid removing an unused parameter from a method. Unused parameters are disallowed, but this is fine?
I am sceptical that these coding standards make for good code!
The main issue is mission assurance. Using the stack or the heap means your variables aren't always at the same memory address. This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.
> If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.
You can and do put the stack and heap pool at fixed memory ranges, so you can always do this. I'm not sold at all with this reasoning.
what leads to better code in terms of understandability & preventing errors
Exceptions (what almost every language does) or Error codes (like Golang)
are there folks here that choose to use error codes and forgo Exceptions completely ?
I actually think Ada would be an easier sell today than it was back then. It seems to me that the software field overall has become more open to a wider variety of languages and concepts, and knowing Ada wouldn't be perceived as widely as career pidgeonholing today. Plus, Ada is having a bit of a resurgence with stuff like NVidia picking SPARK.
Criticism is fair however: they did probably extend themselves too far with the helmet technology, and I do have concerns about touch screens in cockpits (a touch screen requires you to take your eyes off of a target to move your hand to the right location, rather than locating a button by touch).
Right now it is also the single most advance combat airplane, built in any number, which exists anywhere in the world and guarantees that the USA will be able to convincingly assert air dominance in any conflict.
That is of course not to say that exceptions and error codes are the same.
That explains all the delays on the F-35....,
I actually do this as well, but in addition I log out a message like, "value was neither found nor not found. This should never happen."
This is incredibly useful for debugging. When code is running at scale, nonzero probability events happen all the time, and being able to immediately understand what happened - even if I don't understand why - has been very valuable to me.
Reading through the JSF++ coding standards I see they ban exceptions, ban the standard template library, ban multiple inheritance, ban dynamic casts, and essentially strip C++ down to bare metal with one crucial feature remaining: automatic destructors through RAII. When a variable goes out of scope, cleanup happens. That is the entire value proposition they are extracting from C++, and it made me wonder if C could achieve the same thing without dragging along the C++ compiler and all its complexity.
GLib is a utility library that extends C with better string handling, data structures, and portable system abstractions, but buried within it is a remarkably elegant solution to automatic resource management that leverages a GCC and Clang extension called the cleanup attribute. This attribute allows you to tag a variable with a function that gets called automatically when that variable goes out of scope, which is essentially what C++ destructors do but without the overhead of classes and virtual tables.
The heart of GLib's memory management system starts with two simple macros: g_autofree and g_autoptr. The g_autofree macro is deceptively simple. You declare a pointer with this attribute and when the pointer goes out of scope, g_free is automatically called on it. No manual memory management, no remembering to free at every return path, no cleanup sections with goto statements. The pointer is freed whether you return normally, return early due to an error, or even if somehow the code takes an unexpected path. This alone eliminates the majority of memory leaks in typical C programs because most memory management is just malloc and free, or in GLib's case, g_malloc and g_free.
The g_autoptr macro is more sophisticated. While g_autofree works for simple pointers to memory, g_autoptr handles complex types that need custom cleanup functions. A file handle needs fclose, a database connection needs a close function, a custom structure might need multiple cleanup steps. The g_autoptr macro takes a type name and automatically calls the appropriate cleanup function registered for that type. This is where GLib shows its maturity because the library has already registered cleanup functions for all its own types. GError structures are freed correctly, GFile objects are unreferenced, GInputStream objects are closed and released. Everything just works.
Behind these macros is something called G_DEFINE_AUTOPTR_CLEANUP_FUNC, which is how you teach GLib about your own types. You write a cleanup function that knows how to properly destroy your structure, then you invoke this macro with your type name and cleanup function, and from that moment forward you can use g_autoptr with your type. The macro generates the necessary glue code that connects the cleanup attribute to your function, handling all the pointer indirection correctly. This is critical because the cleanup attribute passes a pointer to your variable, not the variable itself, which means for a pointer variable it passes a double pointer, and getting this wrong leads to crashes or memory corruption.
The third member of this is g_auto, which handles stack-allocated types. Some GLib types like GString are meant to live on the stack but still need cleanup. A GString internally allocates memory for its buffer even though the GString structure itself is on the stack. The g_auto macro ensures that when the structure goes out of scope, its cleanup function runs to free the internal allocations. Heap pointers, complex objects, and stack structures all get automatic cleanup.
What's interesting about this system is how it composes. You can have a function that opens a file, allocates several buffers, creates error objects, and builds complex data structures, and you can simply decl...
Note that both MISRA and AUTOSAR's guidelines have been combined into a single standard "MISRA C++ 2023" which has been updated for C++17.
Breaking Down the AUTOSAR C++14 Coding Guidelines - https://www.parasoft.com/blog/breaking-down-the-autosar-c14-...