Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

youtube.com

Post reply on HN
Print view View original

91–100 of 451 posts

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

#91

Post by alchemio »

elteto wrote: post #79
vodou wrote: post #35

Earlier quoted context omitted.

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.)

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, ty…

You can use std containers in a no-exceptions environment. Just know that if an error occurs the program will terminate.

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

#92

Post by addaon »

time4tea wrote: post #80
msla wrote: post #51

Earlier quoted context omitted.

Especially since there is a widely recognized way to ignore a parameter: (void) a; Every C programmer beyond weaning knows that.

The point really was that the unused method parameter should in almost all cases be removed, not that some trick should be used to make it seem used, and this is the wrong trick!

Sometimes. But sometimes you have a set of functions that are called through function pointers that need the same signature, and one or more of them ignore some of the arguments. These days I’d spell that __attribute__((unused)); but it’s a perfectly reasonable case.

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

#93

Post by addaon »

vodou wrote: post #41
garyfirestorm wrote: post #31

Earlier quoted context omitted.

You’re joking right? That autogenerated code is generally garbage and spaghetti code. It was probably the reason for Toyotas unintended acceleration glitch.

Modern autogenerated C code from Simulink is rather effective. It is neither garbage nor spaghetti, it is just... peculiar.

It’s also much, much more resource intensive (both compute and memory) than what a human would right for the same requirements.

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

#94

Post by binary132 »

time4tea wrote: post #45

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!

It’s very weird how none of the sibling comments understood what it were saying is wrong with this.

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

#95

Post by zozbot234 »

tialaramex wrote: post #30
mwkaufma wrote: 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 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.

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

#96

Post by tialaramex »

time4tea wrote: post #45

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!

Studies have looked at MISRA, I'm not aware of any for the JSF guidelines. For MISRA there's a mix, some of the rules seem to be effective (fewer defects in compliant software), some are the opposite (code which obeys these rules is more likely to have defects) and some were irrelevant.

Notably this document is from 2005. So that's after C++ was standardized but before their second bite of that particular cherry and twenty years before its author, Bjarne Stroustrup suddenly decides after years of insisting that C++ dialects are a terrible idea and will never be endorsed by the language committee, that in fact dialects (now named "profiles") are the magic ingredient to fix the festering problems with the language.

While Laurie's video is fun, I too am sceptical about the value of style guides, which is what these are. "TABS shall be avoided" or "Letters in function names shall be lowercase" isn't because somebody's aeroplane fell out of the sky - it's due to using a style Bjarne doesn't like.

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

#97

Post by drnick1 »

msla wrote: post #58
mwkaufma wrote: post #2

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

At that point, why not write in C? Do they think it's C/C++ and not understand the difference? > no recursion Does this actually mean no recursion or does it just mean to limit stack use? Because processing a tree, for example, is recursive even if you use an array, for example, instead of the stack to keep track of your progress. The real trick is limiting memory consumption, which requires limiting input size.

You may still want to use classes (where they make sense), references (cleaner syntax than pointers), operator overloading, etc. For example, a linear algebra library is far nicer to write and use in C++.

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

#99

Post by Thaxll »

anonymousiam wrote: post #81

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?

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

#100

Post by CamouflagedKiwi »

garyfirestorm wrote: post #84
AnimalMuppet wrote: post #57

Earlier quoted context omitted.

> It was probably the reason for Toyotas unintended acceleration glitch. Do you have any evidence for "probably"?

I know for the fact simulink generates spaghetti and spaghetti code was partially blamed for Toyotas problems. Hence the inference See https://www.safetyresearch.net/toyota-unintended-acceleratio...

That's a nonsensical connection. "Spaghetti code" is a very general term, that's nowhere near specific enough for the two to be related.

"I know for a fact that Italian cooks generate spaghetti, and the deceased's last meal contained spaghetti, therefore an Italian chef must have poisoned him"

Post reply on HN