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

351–360 of 451 posts

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

#351

Post by tatjam »

repelsteeltje wrote: post #293
izacus wrote: post #286

Earlier quoted context omitted.

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?

As a quick example, compare doing embedded work with a C static uint8_t[MAX_BUFFER_SIZE] alongside a FreeRTOS semaphore and counter for the number of bytes written, vs using Rust's heapless::Vec, behind a embassy Mutex.

The first will be a real pain, as you now have 3 global variables, and the second will look pretty much like multi-threaded Rust running on a normal OS, but with some extra logic to handle the buffer growing too big.

You can probably squeeze more performance out of the C code, specially if you know your system in-depth, but (from experience) it's very easy to lose track of the program's state and end up shooting your foot.

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

#352

Post by galangalalgol »

nmfisher wrote: post #334
reactordev wrote: post #329

Earlier quoted context omitted.

They need to have very strict security clearance requirements and maintain them throughout the life of the project or their tenure. People don’t realize this isn’t some little embedded app you throw on an ESP32. You’ll be interviewed, your family, your neighbors, your school teachers, your past bosses, your cousin once removed, your sheriff, your past lovers, and even your old childhood friends. Your life goes under…

I went through the TS positive vetting process (for signals intelligence, not writing software for fighter jets, but the process is presumably the same). If I were back on the job market, I’d be demanding a big premium to go through it again. It’s very intrusive, puts significant limitations on where you can go, and adds significant job uncertainty (since your job is now tied to your clearance).

Not to mention embedded software is often half the pay of a startup and defense software often isn't work from home. Forget asking what languages they can hire for. They are relying on the work being interesting to compensate for dramatically less pay and substantially less pleasant working conditions. Factor in some portion of the workforce has ethical concerns working in the sector and you can see they will get three sorts of employees. Those who couldn't get a job elsewhere, those who want something cool on their resume, and those who love the domain. And they will lose the middle category right around the time they become productive members of the team because it was always just a stepping stone.

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

#353

Post by reactordev »

ecshafer wrote: post #348
reactordev wrote: post #340

Earlier quoted context omitted.

Yes but like a certification, that clearance is yours, not the companies. You take it with you. It lasts a good while. There are plenty of government companies that would love you if you had one. Northrop, Lockheed, Boeing, etc.

An Engineering degree and a TS is basically a guaranteed job. They might not be the flashiest FAANG jobs, but it is job security. In this downturn where people talk about being unable to find jobs for years in big cities, I look around my local area and Lockheed, BAE, Booze Allen, etc they have openings.

My issue is you end up dealing with dopes who don't want to learn, just want to milk the money and the job security, and actively fight you when you try to make things better. Institutionalized.

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

#354

Post by galangalalgol »

skepti2 wrote: post #322
serf wrote: post #317

Earlier quoted context omitted.

>What is the proof for that, especially considering events like Ariane 5? Ariane 5 is a nice anti-ada catchphrase, but ada is probably the most used language for war machines in the United States. now the argument can be whether or not the US military is superior to X; but the fact that the largest military in the world is filled to the brim with warmachines running ada code is testament itself to the effectiveness o…

But Ada had for a number of years a mandate to require its usage [0]. That should have been an extreme competitive advantage. And even then, C++ is still used these days for some US military projects, like F-35. Though I don't know whether the F-35 is successful or not, if it is not, that could be an argument against C++. Ada is almost non-existent outside its niche. The main companies arguing for Ada appear to be th…

Poking around it looks like ada is actually the minority now. Everything current is either transitioning to c++ or started that way. The really old but still used stuff is often written in weird languages like jovial or in assembly.

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

#355

Post by uecker »

torben-friis wrote: post #347
uecker wrote: post #295

Earlier quoted context omitted.

And I like using enums in C ;-) The compiler tells you to cover all branches. https://godbolt.org/z/bY1P9Kx7n

Rust is a bit smarter than that, in that it covers exhaustiveness of possible states, for more than just enums: fn g(x: u8) { match x { 0..=10 => {}, 20..=200 => {}, } } That for example would complain about the ranges 11 to 19 and 201 to 255 not being covered. You could try to map ranges to enum values, but then nobody would guarantee that you covered the whole range while mapping to enums so you’d be moving the pro…

In principle C compilers can do this too https://godbolt.org/z/Ev4berx8d although you need to trick them to do this for you. This could certainly be improved.

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

#356

Post by superxpro12 »

mrgaro wrote: post #235
Animats wrote: post #159

Earlier quoted context omitted.

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

We call this "explosive deallocation". Destructors have a whole new meaning.

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

#357

Post by superxpro12 »

mrgaro wrote: post #250
bboygravity wrote: post #222

Earlier quoted context omitted.

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.

I remember having this argument with my professor at the school, who insisted that a function should have only one "return" clause at the very end. Even as I tried, I could not get him to explain why this would be valuable and how does this produce better code, so I'm interested on hearing your take on this?

It helps prevent bugs with state. The apple login bypass bug comes to mind.

Basically, you have code in an "if" statement, and if you return early in that if statement, you might have code that you needed to run, but didnt.

Forcing devs to only "return once" encourages the dev to think through any stateful code that may be left in an intermediate state.

In practice, at my shop, we permit early returns for trivial things at the top of a function, otherwise only one return at the bottom. That seems to be the best of both worlds for this particular rule.

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

#358

Post by superxpro12 »

stackghost wrote: post #27
barfoure wrote: post #5

Do avionics in general subscribe to MISRA C/C++ or do they go even further with an additional (or different) approach?

Depends on the company in my experience. I've seen some suppliers that basically just wire up the diagram in Matlab/simulink and hit Autocode. No humans actually touch the C that comes out. Honestly I think that's probably the correct way to write high reliability code.

I just vomited in my mouth a little. Please god no.

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

#359

Post by superxpro12 »

cpgxiii wrote: post #76
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.

In the case of the Toyota/Denso mess, the code in question had both auto-generated and hand-written elements, including places where the autogenerated code had been modified by hand later. That is the worst place to be, where you no longer have whatever structure and/or guarantees the code gen might provide, but you also don't have the structure and choices that a good SWE team would have to develop that level of com…

The toyota code was a case of truly abysmal software development methodology. The resultant code they released was so bad that neither NASA, nor Barr, nor Koopman could successfully decipher. (Although Barr posited that the issue was VERY LIKELY in one of a few places with complex multithreaded interactions).

Which therein lies the clue. They wrote software that was simply unmaintainable. Autogenerated code isnt any better.

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

#360

Post by goalieca »

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

I’ve learned most languages on the job: c#, php, golang, JavaScript, …

I know others who learned ADA on the job.

It’s not too terrible.

Post reply on HN