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

291–300 of 451 posts

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

#291

Post by skepti »

pjmlp wrote: post #290
skepti wrote: post #280

Earlier quoted context omitted.

Another factor for Ada not being more popular is probably: 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 execu…

People love to point that out, missing the amount of failures in C derived languages.

But C-derived languages are also used much more. And it still shows that Ada does not automatically make software correct and robust. It presumably did indeed make Ada less popular than if it had not happened.

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

#292

Post by dotancohen »

amluto wrote: post #251
dotancohen wrote: post #245

Earlier quoted context omitted.

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…

I'm not working on anything life-critical, one additional layer of redundancy is all I budget for. If both my database is down and my local filesystem is full simultaneously, things have gone bad and I've likely got lots of other symptoms I'm going to find to direct me.

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

#293

Post by repelsteeltje »

izacus wrote: post #286
repelsteeltje wrote: post #274

Earlier quoted context omitted.

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.

They're considered impractical mostly because language tooling doesn't support them appropriately.

Can you elaborate?

For instance, how would better tooling help with storing a TCP buffer in global memory?

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

#294

Post by windward »

tialaramex wrote: post #96
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…

Bjarne's just a guy, he doesn't control how the C++ committee vote and doesn't remotely control how you or I make decisions about style.

And boiling down these guidelines to style guides is just incorrect. I've never had a 'nit: cyclomatic complexity, and uses dynamic allocation'.

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

#295

Post by uecker »

torben-friis wrote: post #185
don-code wrote: post #142

> All if, else if constructs will contain either a final else clause or a comment indicating why a final else clause is not necessary. I actually do this as well, but in addition I log out a message like, "value was neither found nor not found. This should never happen." This is incredibly useful for debugging. When code is running at scale, nonzero probability events happen all the time, and being able to immediatel…

I like rust matching for this reason: You need to cover all branches. In fact, not using a default (the else clause equivalent) is ideal if you can explicitly cover all cases, because then if the possibilities expand (say a new value in an enum) you’ll be annoyed by the compiler to cover the new case, which might otherwise slip by.

And I like using enums in C ;-) The compiler tells you to cover all branches.

https://godbolt.org/z/bY1P9Kx7n

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

#296

Post by uecker »

creato wrote: post #234
vlovich123 wrote: post #214

Earlier quoted context omitted.

That is not the same thing at all. Unreachable means that entire branch cannot be taken and the compiler is free to inject optimizations assuming that’s the case. It doesn’t need to crash if the violation isn’t met - indeed it probably won’t. It’s the equivalent of having something like x->foo(); if (x == null) { Return error…; } This literally caused a security vulnerability in the Linux kernel because it’s UB to de…

You're right, the thing I linked to do does exactly that. I should have read it more closely. The projects that I've worked on, unconditionally define it as a thing that crashes (e.g. `std::abort` with a message). They don't actually use that C/C++ thing (because C23 is too new), and apparently it would be wrong to do so.

You can use the standard feature with the unreachable sanitizer: https://godbolt.org/z/3hePd18Tn

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

#297

Post by uecker »

throwaway2037 wrote: post #153
uecker wrote: post #132

Earlier quoted context omitted.

A multi-inhertiance system is certainly not something somebody who "was thinking in C" would ever come up with. This sounds more like a true C++ mess.

I worked on a pure C system early in my career. They implemented multiple inheritance (a bit like Perl/Python MRO style) in pure C. It was nuts, but they didn't abuse it, so it worked OK. Also, serious question: Are they any GUI toolkits that do not use multiple inheritance? Even Java Swing uses multiple inheritance through interfaces. (I guess DotNet does something similar.) Qt has it all over the place.

I take this back ;-) People come up with crazy things. Still I would not call this "C thinking". Building object-oriented code in C is common though and works nicely.

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

#298

Post by pjmlp »

skepti wrote: post #291
pjmlp wrote: post #290

Earlier quoted context omitted.

People love to point that out, missing the amount of failures in C derived languages.

But C-derived languages are also used much more. And it still shows that Ada does not automatically make software correct and robust. It presumably did indeed make Ada less popular than if it had not happened.

People still die in car crashes when wearing seatbelts, ergo seatbelts are useless.

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

#299

Post by bluGill »

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!

    #if otherbuild
        dosomething(param);
     #endif
the above type of thing happens once in a while. nos the paramater is needed but the normal build doesn't use it
Post reply on HN