←back to thread

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

(www.youtube.com)
327 points AareyBaba | 1 comments | 07 Dec 25 18:07 UTC | HN request time: 0s | source
Show context
anonymousiam ◴[07 Dec 25 20:15 UTC] No.46184727[source]▶
The same is true for the software that runs many satellites. Use of the STL is prohibited.

The main issue is mission assurance. Using the stack or the heap means your variables aren't always at the same memory address. This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.

replies(7): >>46185566 #>>46187219 #>>46188652 #>>46189307 #>>46190613 #>>46191199 #>>46196185 #
5d41402abc4b ◴[08 Dec 25 05:18 UTC] No.46188652[source]▶
> Using the stack or the heap means your variables aren't always at the same memory address

Where do you place the variables then? as global variables? and how do you detect if a memory cell has gone bad?

replies(1): >>46189537 #
cminmin ◴[08 Dec 25 07:47 UTC] No.46189537[source]▶
your programs have a data segment. its not the heap nor the stack... and it can be (depending on loader/linker) a source of reliable object->address mappings as its not dynamically populated.
replies(1): >>46189796 #
repelsteeltje ◴[08 Dec 25 08:30 UTC] No.46189796[source]▶
That sounds like your answer is: "Yes, global variables".

That may be a perfectly good solution in many embedded environments, but in most other context's global variables are considered bad design or very limiting and impractical.

replies(3): >>46190061 #>>46190686 #>>46190979 #
TuxSH ◴[08 Dec 25 10:29 UTC] No.46190686[source]▶
> global variables are considered bad design

Global mutable variables, and they usually tend to be grouped into singletons (solving initialization issues, and fewer people bat an eye)

replies(1): >>46196544 #
1. RealityVoid ◴[08 Dec 25 19:30 UTC] No.46196544[source]▶
Even global mutable variables are a problem only because they lend to spaghetti code and messy state handling if you use them in multiple places. But you could just... make a global variable and then handle it like you would a variable init with malloc. No functional issue there.