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

231–240 of 451 posts

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

#231

Post by ecshafer »

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

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

#232

Post by ecshafer »

fragmede wrote: post #193
GoblinSlayer wrote: post #104

Earlier quoted context omitted.

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

do they use f35io.h?

Depends. You use vendor specific libraries for hard real time systems, or in house libraries, or roll your own functions.

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

#233

Post by treyd »

bluecalm wrote: post #125
ErroneousBosh wrote: post #116

Earlier quoted context omitted.

Golang is exactly the same. It's extremely annoying until it's suddenly very useful and has prevented you doing something unintended.

I fail to see how a warning doesn't achieve the same thing while allowing you to iterate faster. Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.

You're not supposed to question the wisdom of the Go developers. They had a very good reason for making unused variables be an unconfigurable hard error, and they don't need to rigorously justify it.

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

#234

Post by creato »

vlovich123 wrote: post #214
creato wrote: post #202

Earlier quoted context omitted.

The "standard" (typically defined in projects I'm familiar with, and as of C23, an actual standard) is "unreachable": https://en.cppreference.com/w/c/program/unreachable.html

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.

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

#235

Post by mrgaro »

Animats wrote: post #159
jandrewrogers wrote: post #8

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

As is common in hard real time code, there is no dynamic allocation during operation: allocation/deallocation from/to the free store (heap) shall not occur after initialization. This works fine when the problem is roughly constant, as it was in, say, 2005. But what do things look like in modern AI-guided drones?

There are missiles in which the allocation rate is calculated per second and then the hardware just has enough memory for the entire duration of the missile's flight plus a bit more. Garbage collection is then done by exploding the missile on the target ;)

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

#236

Post by pjmlp »

metaltyphoon wrote: post #209
pjmlp wrote: post #88

Earlier quoted context omitted.

Check C# 10, Python 3.14, D, Haskell,...

I don't consider C# a very large language. Most of what has been added removed boilerplate code. Swift, a much younger language, is way more complicated IMO

Someone doing maintenance work on C# project might find code going all the way back to C# 1.0.

Also improvements to low level programming, being done since C# 7, a few semantic changes, aren't for removing boilerplate code.

Then since a language is useless without its standard library, there have beem plenty of changes on how to do P/Invoke, COM interop, development of Web applications, and naturally knowing in what release specific features were introduced.

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

#237

Post by katzenversteher »

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.

For me it's mostly about indentation / scope depth. So I prefer to have some early exits with precondition checks at the beginning, these are things I don't have to worry about afterwards and I can start with the rest at indentation level "0". The "real" result is at the end.

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

#239

Post by jandrewrogers »

Animats wrote: post #213
jandrewrogers wrote: post #171

Earlier quoted context omitted.

Why would the modern environment materially change this? The initialized resource allocation reflects the limitations of the hardware. That budget is what it is. I can't think of anything about "modern AI-guided drones" that would change the fundamental mechanics. Some systems support very elastic and dynamic workloads under fixed allocation constraints.

Basic flight control is a fixed-sized problem. More military aircraft systems now on what the environment and enemy are doing.

The compute side of real-time tracking and analysis of entity behavior in the environment is bottlenecked by what the sensors can resolve at this point. On the software side you really can’t flood the zone with enough drones etc such that software can’t keep up.

These systems have limits but they are extremely high and in the improbable scenario that you hit them then it is a priority problem. That design problem has mature solutions from several decades ago when the limits were a few dozen simultaneous tracks.

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

#240

Post by _flux »

mmooss wrote: post #216
coderenegade wrote: post #211

Earlier quoted context omitted.

What's the difference between autogenerated C code and compiling to assembly or machine code? Seems academic to me. The main flaw of autocode is that a human can't easily read and validate it, so you can't really use it as source code. In my experience, this is one of the biggest flaws of these types of systems. You have to version control the file for whatever proprietary graphical programming software generated the…

> What's the difference between autogenerated C code and compiling to assembly or machine code? Seems academic to me. It's an interesting question and point, but those are two different things and there is no reason to think you'll get the same results. Why not compile from natural language, if that theory is true?

Natural language does not have a specification, while both C and assembly do.
Post reply on HN