Live data from Hacker News

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

youtube.com

101–110 of 451 posts

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

#102
post #99

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 contin…

Can't this be done at runtime? Like the underlying calls can black list hardware address on read/write faults?

If you have memory to spare and are using hardware with an MMU, you can remap your logical address to a different page. Linux can do this, but only for user memory.

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

#103

Earlier quoted context omitted.

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…

The tail recursion operator is a nice idea, but the extra `become` keyword is annoying. I think the syntax should be `return as`: it uses existing keywords, is unambiguous and starts with `return` which tail recursion is a special case of.

Traditionally the time for bike shedding the exact syntax is much closer to stabilization.

Because Rust is allowed (at this sort of distance in time) to reserve new keywords via editions, it's not a problem to invent more, so I generally do prefer new keywords over re-using existing words but I'm sure I'd be interested in reading the pros and cons.

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

#104

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

In general, are these good recommendations for building software for embedded or lower-spec devices? I don't know how to do preprocessor macros anyhow, for instance - so as i am reading this i am like "yeah, i agree..." until the no stdio.h!

stdio.h is not what you would use in safe code.

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

#105
post #56

a = a; // misra Actual code i have seen with my own eyes. (Not in F-35 code) Its a way to avoid removing an unused parameter from a method. Unused parameters are disallowed, but this is fine? I am sceptical that these coding standards make for good code!

For C, the proper/expected/standard way to reference a variable without accessing it is a cast to void: (void) a; I'm sure there are commonly-implemented compiler extensions, but this is the normal/native way and should always work.

Not if you use GCC.

https://godbolt.org/z/zYdc9ej88

clang gets this right.

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

#107
post #105
post #56

Earlier quoted context omitted.

For C, the proper/expected/standard way to reference a variable without accessing it is a cast to void: (void) a; I'm sure there are commonly-implemented compiler extensions, but this is the normal/native way and should always work.

Not if you use GCC. https://godbolt.org/z/zYdc9ej88 clang gets this right.

It does work in GCC to suppress unused variable warnings. Just not for function calls I guess.

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

#108
post #102
post #99

Earlier quoted context omitted.

Can't this be done at runtime? Like the underlying calls can black list hardware address on read/write faults?

If you have memory to spare and are using hardware with an MMU, you can remap your logical address to a different page. Linux can do this, but only for user memory.

This assumes that the operating system can run. If the memory corruption impacts the OS, then it may be impossible to recover. As the systems (and software) have become more complex, keeping these Mission Assurance best practices becomes more important, but the modern generation of developers sometimes loses sight of this.

A good example of what I'm talking about is a program that I was peripherally involved with about 15 years ago. The lead wanted to abstract the mundane details from the users (on the ground), so they would just "register intent" with the spacecraft, and it would figure out how to do what was wanted. The lead also wanted to eliminate features such as "memory dump", which is critical to the anomaly resolution process. If I had been on that team, I would have raised hell, but I wasn't, and at the time, I needed that team lead as an ally.

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

#109
https://web.archive.org/web/20111219004314/http://journal.th... (referenced, at least tangentially, in the video) is a piece from the engineering lead which does a great job discussing Why C++. The short summary is "they couldn't find enough people to write Ada, and even if they could, they also couldn't find enough Ada middleware and toolchain."

I actually think Ada would be an easier sell today than it was back then. It seems to me that the software field overall has become more open to a wider variety of languages and concepts, and knowing Ada wouldn't be perceived as widely as career pidgeonholing today. Plus, Ada is having a bit of a resurgence with stuff like NVidia picking SPARK.

Post reply on HN