Live data from Hacker News

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

youtube.com

21–30 of 451 posts

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

#21
post #2

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

yup, same for any real time code, new/malloc/free/delete use hidden mutexes and can cause priority inversion as a result - heisenbugs, that audio/video dropout that happens rarely and you can't quite catch - best to code to avoid them

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

#23

Earlier quoted context omitted.

i.e. standard practice for every C++ code base I've ever worked on

What industry do you work in? Modern RAII practices are pretty prevalent

This is common in embedded systems, where there is limited memory and no OS to run garbage collection.

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

#24

Earlier quoted context omitted.

What industry do you work in? Modern RAII practices are pretty prevalent

What does RAII have to do with any of the above?

Well if you're using the standard library then you're not really paying attention to allocations and deallocations for one. For instance, the use of std::string. So I guess I'm wondering if you work in an industry that avoids std?

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

#25
post #2

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

I've worked on a playout system for broadcast television. The software has to run for years at a time and not have any leaks, We need to send out one frame of television exactly on time, every time.

It is "C++", but we also follow the same standards. Static memory allocation, no exceptions, no recursion. We don't use templates. We barely use inheritance. It's more like C with classes.

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

#26
post #14

Earlier quoted context omitted.

What does RAII have to do with any of the above?

0 allocations after the program initializes.

RAII doesn't imply allocating.

My guess is that you're assuming all user defined types, and maybe even all non-trivial built-in types too, are boxed, meaning they're allocated on the heap when we create them.

That's not the case in C++ (the language in question here) and it's rarely the case in other modern languages because it has terrible performance qualities.

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

#27
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.

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

#30
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 be tail recursive" and then the compiler is either going to agree and deliver the optimized machine code, or disagree and your program won't compile, so in neither case have you introduced a stack overflow.

Rust's Drop mechanism throws a small spanner into this, in principle if every function foo makes a Goose, and then in most cases calls foo again, we shouldn't Drop each Goose until the functions return, which is too late, that's now our tail instead of the call. So the `become` feature AIUI will spot this, and Drop that Goose early (or refuse to compile) to support the optimization.

Post reply on HN