←back to thread

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

(www.youtube.com)
327 points AareyBaba | 10 comments | 07 Dec 25 18:07 UTC | HN request time: 0.001s | source | bottom
Show context
mwkaufma ◴[07 Dec 25 18:15 UTC] No.46183728[source]▶
TL;DR

- no exceptions

- no recursion

- no malloc()/free() in the inner-loop

replies(9): >>46183820 #>>46183900 #>>46184073 #>>46184113 #>>46184198 #>>46184398 #>>46184472 #>>46184588 #>>46185500 #
wiseowise ◴[07 Dec 25 18:36 UTC] No.46183900[source]▶
That’s hardly 90% of C++.
replies(2): >>46183975 #>>46184047 #
elteto ◴[07 Dec 25 18:54 UTC] No.46184047[source]▶
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.

replies(2): >>46184298 #>>46184314 #
1. vodou ◴[07 Dec 25 19:25 UTC] No.46184298[source]▶
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.)
replies(2): >>46184320 #>>46184674 #
2. theICEBeardk ◴[07 Dec 25 19:28 UTC] No.46184320[source]▶
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.
replies(2): >>46184444 #>>46184552 #
3. Espressosaurus ◴[07 Dec 25 19:41 UTC] No.46184444[source]▶
Yeah. I unfortunately moved to an APU where code size isn't an issue so I never got the chance to see how well that analysis translated to the work I do.

Provocative talk though, it upends one of the pillars of deeply embedded programming, at least from a size perspective.

4. vodou ◴[07 Dec 25 19:52 UTC] No.46184552[source]▶
Need to check it out. I guess you mean these:

- C++ Exceptions Reduce Firmware Code Size, ACCU [1]

- C++ Exceptions for Smaller Firmware, CppCon [2]

[1]: https://www.youtube.com/watch?v=BGmzMuSDt-Y

[2]: https://www.youtube.com/watch?v=bY2FlayomlE

5. elteto ◴[07 Dec 25 20:09 UTC] No.46184674[source]▶
Not exactly sure what your experience is, but if you work with in an -fno-exceptions codebase then you know that STL containers are not usable in that regime (with the exception of std::tuple it seems, see freestanding comment below). I would argue that the majority of use cases of the STL is for its containers.

So, what exact parts of the STL do you use in your code base? Most be mostly compile time stuff (types, type trait, etc).

replies(1): >>46185134 #
6. alchemio ◴[07 Dec 25 21:03 UTC] No.46185134[source]▶
You can use std containers in a no-exceptions environment. Just know that if an error occurs the program will terminate.
replies(2): >>46186937 #>>46188021 #
7. elteto ◴[08 Dec 25 00:29 UTC] No.46186937{3}[source]▶
So you can’t use them then.
replies(2): >>46189176 #>>46203535 #
8. WD-42 ◴[08 Dec 25 03:40 UTC] No.46188021{3}[source]▶
We've banned exceptions! If any occur, we just don't catch them.
9. _flux ◴[08 Dec 25 06:45 UTC] No.46189176{4}[source]▶
I don't think it would be typical to depend on exception handling when dealing with boundary conditions with C++ containers.

I mean .at is great and all, but it's really for the benefit of eliminating undefined behavior and if the program just terminates then you've achieved this. I've seen decoders that just catch the std::out_of_range or even std::exception to handle the remaining bugs in the logic, though.

10. account42 ◴[09 Dec 25 11:00 UTC] No.46203535{4}[source]▶
Of course you can, you just need to check your preconditions and limit sizes ahead of time - but you need to do that with exceptions too because modern operating systems overcommit instead of failing allocations and the OOM killer is not going to give you an exception to handle.