TL;DR - no exceptions - no recursion - no malloc()/free() in the inner-loop
The C++ standard for the F-35 Fighter Jet [video]
21–30 of 451 posts
Re: The C++ standard for the F-35 Fighter Jet [video]
#22Re: The C++ standard for the F-35 Fighter Jet [video]
#23Re: The C++ standard for the F-35 Fighter Jet [video]
#24Earlier 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?
Re: The C++ standard for the F-35 Fighter Jet [video]
#25TL;DR - no exceptions - no recursion - no malloc()/free() in the inner-loop
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]
#26Earlier quoted context omitted.
What does RAII have to do with any of the above?
0 allocations after the program initializes.
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]
#27Do avionics in general subscribe to MISRA C/C++ or do they go even further with an additional (or different) approach?
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]
#28Re: The C++ standard for the F-35 Fighter Jet [video]
#29Re: The C++ standard for the F-35 Fighter Jet [video]
#30TL;DR - no exceptions - no recursion - no malloc()/free() in the inner-loop
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.