Live data from Hacker News

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

youtube.com

31–40 of 451 posts

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

#31
post #5

Do avionics in general subscribe to MISRA C/C++ or do they go even further with an additional (or different) approach?

Depends on the company in my experience. I've seen some suppliers that basically just wire up the diagram in Matlab/simulink and hit Autocode. No humans actually touch the C that comes out. Honestly I think that's probably the correct way to write high reliability code.

You’re joking right? That autogenerated code is generally garbage and spaghetti code. It was probably the reason for Toyotas unintended acceleration glitch.

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

#35
post #17

Earlier quoted context omitted.

That’s hardly 90% of C++.

If you compile with -fno-exceptions you just lost almost all of the STL. You can compile with exceptions enabled, use the STL, but strictly enforce no allocations after initialization. It depends on how strict is the spec you are trying to hit.

Not my experience. I work with a -fno-exceptions codebase. Still quite a lot of std left. (Exceptions come with a surprisingly hefty binary size cost.)

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

#36

For those interested, the F-35 (née Joint Strike Fighter) C++ coding standards can be found here, all 142 pages of it: https://www.stroustrup.com/JSF-AV-rules.pdf

From quickly glancing over a couple of pages, that looks sensible. Which makes me curious to see some exceptions to the "shall" rules. With a project of this size, that should give some idea about the usefulness of such standards.

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

#37
post #17

Earlier quoted context omitted.

That’s hardly 90% of C++.

If you compile with -fno-exceptions you just lost almost all of the STL. You can compile with exceptions enabled, use the STL, but strictly enforce no allocations after initialization. It depends on how strict is the spec you are trying to hit.

Are you aware of the Freestanding definition of STL? See here: https://en.cppreference.com/w/cpp/freestanding.html Large and useful parts of it are available if you run with a newer c++ standard.

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

#39
post #35
post #17

Earlier quoted context omitted.

If you compile with -fno-exceptions you just lost almost all of the STL. You can compile with exceptions enabled, use the STL, but strictly enforce no allocations after initialization. It depends on how strict is the spec you are trying to hit.

Not my experience. I work with a -fno-exceptions codebase. Still quite a lot of std left. (Exceptions come with a surprisingly hefty binary size cost.)

Apparently according to some ACCU and CPPCon talks by Khalil Estel this can be largely mitigated even in embedded lowering the size cost by orders of magnitude.

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

#40
post #2

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

Forbidding recursion is pretty annoying. One of the nice things that's on the distant horizon for Rust is an explicit tail recursion operator perhaps named `become`. Unlike naive recursion, which as this video (I haven't followed the link but I'm assuming it is Laurie's recent video) explains risks stack overflow, optimized tail recursion doesn't grow the stack. The idea of `become` is to signal "I believe this can b…

In C, tail recursion is a fairly simple rewrite. I can't think of any complications.

But ... that rewrite can increase the cyclomatic complexity of the code on which they have some hard limits, so perhaps that's why it isn't allowed? And the stack overflow, of course.

Post reply on HN