The C++ standard for the F-35 Fighter Jet [video] • Hacker News Board

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

#121

Post by fweimer » Sun, Dec 07, 2025, 10:34 PM UTC

krashidov wrote: post #49

mwkaufma wrote: post #2

TL;DR - no exceptions - no recursion - no malloc()/free() in the inner-loop

Has anyone else here banned exceptions (for the most part) in less critical settings (like a web app)? I feel like that's the way to go since you don't obscure control flow. I have also been considered adding assertions like TigerBeetle does https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...

Most large open-source projects ban exceptions, often because the project was originally converted from C and is just not compatible with non-local control flow. Or the project originated within an organization which has tons of C++ code that is not exception-safe and is expected to integrate with that.

Some large commercial software systems use C++ exceptions, though.

Until recently, pretty much all implementations seemed to have a global mutex on the throw path. With higher and higher core counts, the affordable throw rate in a process was getting surprisingly slow. But the lock is gone in GCC/libstdc++ with glibc. Hopefully the other implementations follow, so that we don't end up with yet another error handling scheme for C++.

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

#122

Post by tsunagatta » Sun, Dec 07, 2025, 10:34 PM UTC

factorialboy wrote: post #110

Isn't the F35 program considered a failure? Or am I confusing it with some other program?

The F-35 was in development hell for a while for sure, but it’s far from a failure. See the recent deals where it’s been used as a political bargaining chip; it still ended up being a very desirable and capable platform from my understanding.

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

#123

Post by bluecalm » Sun, Dec 07, 2025, 10:35 PM UTC

ivanjermakov wrote: post #71

time4tea wrote: post #45

a = a; // misra 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!

Zig makes it explicit with _ = a; And you would encounter it quite often because unused variable is a compilation error: https://github.com/ziglang/zig/issues/335

Doesn't it make it more likely unused variables stay in the codebase? You want to experiment, the code doesn't compile, you add this (probably by automatic tool), the code now compiles. You're happy with your experiment. As the compiler doesn't complain you commit and junk stays in the code.

Isn't it just bad design that makes both experimenting harder and for unused variables to stay in the code in the final version?

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

#124

Post by joha4270 » Sun, Dec 07, 2025, 10:36 PM UTC

factorialboy wrote: post #110

Isn't the F35 program considered a failure? Or am I confusing it with some other program?

A lot of people have made careers out of telling you that it's a failure, but while not everything about the F-35 is an unquestionable success, it has produced a "cheap" fighter jet that is more capable than all but a handful of other planes.

Definitely not a failure.

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

#125

Post by bluecalm » Sun, Dec 07, 2025, 10:39 PM UTC

ErroneousBosh wrote: post #116

ivanjermakov wrote: post #71

Earlier quoted context omitted.

Zig makes it explicit with _ = a; And you would encounter it quite often because unused variable is a compilation error: https://github.com/ziglang/zig/issues/335

Golang is exactly the same. It's extremely annoying until it's suddenly very useful and has prevented you doing something unintended.

I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.

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

#126

Post by themafia » Sun, Dec 07, 2025, 10:40 PM UTC

TimorousBestie wrote: post #117

factorialboy wrote: post #110

Isn't the F35 program considered a failure? Or am I confusing it with some other program?

The research and development effort went way over budget, the first couple rounds of production were fraught with difficulty, and the platform itself has design issues from being a “one-size-fits-all” compromise (despite also having variants for each service). I haven’t heard anything particularly bad about the software effort, other than the difficulties they had making the VR/AR helmet work (the component never mad…

They oxygen delivery system fails and has left pilots hypoxic.

https://www.nwfdailynews.com/story/news/local/2021/08/02/f-3...

The electrical system performs poorly under short circuit conditions.

https://breakingdefense.com/2024/10/marine-corps-reveals-wha...

They haven't even finished delivering and now have to overhaul the entire fleet due to overheating.

https://nationalsecurityjournal.org/the-f-35-fighters-2-big-...

This program was a complete and total boondoggle. It was entirely the wrong thing to build in peace time. It was a moonshoot for no reason other than to mollify bored generals and greedy congresspeople.

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

#127

Post by zozbot234 » Sun, Dec 07, 2025, 10:40 PM UTC

tialaramex wrote: post #103

zozbot234 wrote: post #95

Earlier quoted context omitted.

The tail recursion operator is a nice idea, but the extra `become` keyword is annoying. I think the syntax should be `return as`: it uses existing keywords, is unambiguous and starts with `return` which tail recursion is a special case of.

Traditionally the time for bike shedding the exact syntax is much closer to stabilization. Because Rust is allowed (at this sort of distance in time) to reserve new keywords via editions, it's not a problem to invent more, so I generally do prefer new keywords over re-using existing words but I'm sure I'd be interested in reading the pros and cons.

The usual argument against a decorated `return` keyword is that a proper tail call is not a true "return" since it has to first drop any locals that aren't passed thru to the tail call. I don't think it's a very good argument because if the distinction of where exactly those implicit drops occur was that important, we'd probably choose to require explicit drops anyway.

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

#128

Post by MathMonkeyMan » Sun, Dec 07, 2025, 10:42 PM UTC

Am4TIfIsER0ppos wrote: post #113

amluto wrote: post #105

Earlier quoted context omitted.

Not if you use GCC. https://godbolt.org/z/zYdc9ej88 clang gets this right.

You've defined that function with an attribute saying not to ignore the returned value. Is it right to explicitly silence an explicit warning?

Sometimes. For example, you might be setting a non-crucial option on a socket, and if it fails you don't even care to log the fact (maybe the logging would be too expensive), so you just ignore the return value of whatever library is wrapping setsockopt.

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

#129

Post by FpUser » Sun, Dec 07, 2025, 10:47 PM UTC

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.

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

#130

Post by d-lisp » Sun, Dec 07, 2025, 10:53 PM UTC

anonymousiam wrote: post #108

amluto wrote: post #102

Earlier quoted context omitted.

If you have memory to spare and are using hardware with an MMU, you can remap your logical address to a different page. Linux can do this, but only for user memory.

This assumes that the operating system can run. If the memory corruption impacts the OS, then it may be impossible to recover. As the systems (and software) have become more complex, keeping these Mission Assurance best practices becomes more important, but the modern generation of developers sometimes loses sight of this. A good example of what I'm talking about is a program that I was peripherally involved with abo…

Wow, but how did they deal with anomalies ?

I mean, even when I have the codebase readily accessible and testable in front of my eyes, I never trust the tests to be enough ? I often spot forgotten edge cases and bugs of various sort in C/embedded projects BECAUSE I run the program, can debug and spot mem issues and whole a lot of other things for which you NEED to gather the most informations you can in order to find solutions ?