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

251–260 of 451 posts

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

#251

Post by amluto »

dotancohen wrote: post #245
amluto wrote: post #191

Earlier quoted context omitted.

I want some defined way to tell the compiler that I am intentionally ignoring the result. I encounter this when trying to do best-effort logging in a failure path. I call some function to log and error and maybe it fails. If it does, what, exactly, am I going to do about it? Log harder?

Yes. When my database logging fails, I write a file that logs the database fail (but not the original log file). When my file logging fails, depending on application, I'll try another way of getting the information (the fact that for file logging failed) out - be that an http request or an email or something else. Databases fail, file systems fill up. Logging logging failures is extremely important.

And when that last way fails, what do you do?

I like to have a separate monitoring process that monitors my process and a separate machine in a different datacenter monitoring that. But at the end of the day, the first process is still going to do try to log, detect that it failed, try the final backup log and then signal to its monitor that it’s in a bad state. It won’t make any decisions that depend on whether the final backup logging succeeds or fails.

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

#252

Post by menaerus »

tomhow wrote: post #223
writtiewrat wrote: post #119

Earlier quoted context omitted.

[flagged]

We've banned this account for continual guidelines breaches across multiple accounts.

You do realize that there's a handful of literally the same people here on HN continuously evangelizing one technology by constantly dissing on the other? Because of the pervasiveness of such accounts/comments it invites other people, myself included, to counter-argue because most of the time the reality they're trying to portray is misrepresented or many times simply wrong. This is harmful and obviously invites for a flame war so how is that not by the same principle you applied to above account a guideline breach too?

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

#253

Post by menaerus »

stackghost wrote: post #186
addaon wrote: post #183

Earlier quoted context omitted.

> All that means is that 10 years ago you had to rely on humans to write the code that today can be done more safely with auto generation. No. It means more than that. There's a cross-product here. On one axis, you have "resources needed", higher for code gen. On another axis, you have "available hardware safety features." If the higher resources needed for code gen pushes you to fewer hardware safety features availa…

HN is a very poor platform for good conversations so we'll have to agree to disagree, as I'm not willing to go further in this format

Codegen from Matlab/Simulink/whatever is good for proof of concept design. It largely helps engineers who are not very good with coding to hypothesize about different algorithmic approaches. Engineers who actually implement that algorithm in a system that will be deployed are coming from a different group with different domain expertise.

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

#254

Post by qart »

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!

You're right. MISRA is a cult. Actual studies[1][2] have shown many of their rules to be harmful rather than helpful. I have worked in multiple safety-critical industries. MISRA is almost always enforced by bureaucrats who don't understand source code at all, or by senior developers who rose up ranks as code monkeys. One such manager was impressed with Matlab because Matlab-generated C code was always MISRA compliant, whereas the code my company was giving them had violations. Never mind the fact that every function of the generated, compliant code had variables like tmp01, tmp02, tmp03, etc.

There are many areas of software where bureaucracy requires MISRA compliance, but that aren't really safety-critical. The code is a hot mess. There are other areas that require MISRA compliance and the domain is actually safety-critical (e.g. automotive software). Here, the saving grace is (1) low complexity of each CPU's codebase and (2) extensive testing.

To people who want actual safety, security, portability, I tell them to learn from examples set by the Linux kernel, SQLite, OpenSSL, FFMpeg, etc. Modern linters (even free ones) are actually valuable compared to MISRA compliance checkers.

[1] https://ieeexplore.ieee.org/abstract/document/4658076

[2] https://repository.tudelft.nl/record/uuid:646de5ba-eee8-4ec8...

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

#255

Post by KolmogorovComp »

blub wrote: post #249
ecshafer wrote: post #231

Earlier quoted context omitted.

I've always strongly disliked this argument of not enough X programmers. If the DoD enforces the requirement for Ada, Universities, job training centers, and companies will follow. People can learn new languages. And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.

The exact opposite of what you suggest already happened: Ada was mandated and then the mandate was revoked. It’s generally a bad idea to be the only customer of a specific product, because it increases costs. > And the F35 and America's combat readiness would be in a better place today with Ada instead of C++ What’s the problem with the F35 and combat readiness? Many EU countries are falling over each-other to buy it…

> Many EU countries are falling over each-other to buy it

They are not buying it for its capabilities though, but to please their US ally/bully which would have retaliated economically otherwise.

See the very recent Swiss case were theirs pilots had chosen another aircraft (the french Rafale), only to be disavowed by their politics later on.

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

#256

Post by dragonwriter »

bboygravity wrote: post #222
platinumrad wrote: post #163

Earlier quoted context omitted.

The "good" rules are like "don't write off the end of an array", and the bad ones are like "no early returns" or "variable names must not be longer than 6 characters". 95% of the "good" rules are basically just longer ways of saying "don't invoke undefined behavior".

Why is "no early returns" not a good rule? I do early returns in code I write, but ONLY because everybody seems to do it. I prefer stuff to be in predictable places: variables at the top, return at the end. Simpler? Delphi/Pascal style.

> Why is "no early returns" not a good rule?

It might be a good guideline.

Its not a good rule because slavishly following results in harder to follow code written to adhere to it.

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

#257

Post by cminmin »

5d41402abc4b wrote: post #227
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…

> 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?

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.

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

#258

Post by cminmin »

menaerus wrote: post #248
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…

So none of the functions you implement have in/out parameters?

if you use few you can have em all in the registers perhaps (not sure what arch they rollin?)

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

#259

Post by skepti »

ecshafer wrote: post #231
bri3d wrote: post #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 the…

I've always strongly disliked this argument of not enough X programmers. If the DoD enforces the requirement for Ada, Universities, job training centers, and companies will follow. People can learn new languages. And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.

Why require that companies use a specific programming language instead of requiring that the end product is good?

> And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.

What is the evidence for this? Companies selling Ada products would almost certainly agree, since they have a horse in the race. Ada does not automatically lead to better, more robust, safer or fully correct software.

Your line of argument is dangerous and dishonest, as real life regrettably shows.[0]

[0]: https://en.wikipedia.org/wiki/Ariane_flight_V88

> The failure has become known as one of the most infamous and expensive software bugs in history.[2] The failure resulted in a loss of more than US$370 million.[3]

> The launch failure brought the high risks associated with complex computing systems to the attention of the general public, politicians, and executives, resulting in increased support for research on ensuring the reliability of safety-critical systems. The subsequent automated analysis of the Ariane code (written in Ada) was the first example of large-scale static code analysis by abstract interpretation.[9]

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

#260

Post by SideburnsOfDoom »

bboygravity wrote: post #222
platinumrad wrote: post #163

Earlier quoted context omitted.

The "good" rules are like "don't write off the end of an array", and the bad ones are like "no early returns" or "variable names must not be longer than 6 characters". 95% of the "good" rules are basically just longer ways of saying "don't invoke undefined behavior".

Why is "no early returns" not a good rule? I do early returns in code I write, but ONLY because everybody seems to do it. I prefer stuff to be in predictable places: variables at the top, return at the end. Simpler? Delphi/Pascal style.

The "no early returns" rule came about because was a good rule in context, specifically C and FORTRAN code before roughly 1990. It was part of "structured programming", contemporary to "Go To Statement Considered Harmful", Dijkstra, 1968. And it became received wisdom - i.e. a rule that people follow without close examination.

For example of the rule, a function might allocate, do something and then de-allocate again at the end of the block. A second exit point makes it easy to miss that de-allocation, and so introduce memory leaks that only happen sometimes. The code is harder to reason about and the bugs harder to find.

source:

> A problem with early exit is that cleanup statements might not be executed. ... Cleanup must be done at each return site, which is brittle and can easily result in bugs.

https://en.wikipedia.org/wiki/Structured_programming#Early_r...

About 90% of us will now be thinking "but that issue doesn't apply to me at all in $ModernLang. We have GC, using (x) {} blocks, try-finally, or we have deterministic finalisation, etc."

And they're correct. In most modern languages it's fine. The "no early returns" rule does not apply to Java, TypeScript, C#, Rust, Python, etc. Because these languages specifically made early return habitable.

The meta-rule is that some rules persist past the point when they were useful. Understand what a rule is for and then you can say when it applies at all. Rules without reasons make this harder. Some rules have lasted: we typically don't use goto at all any more, just structured wrappers of it such as if-else and foreach

Post reply on HN