News for hackers. Stuff that matters.
Re:The C++ standard for the F-35 Fighter Jet [video] by izacus on Monday December 08, 2025 @04:06AM (#46190061)
They're considered impractical mostly because language tooling doesn't support them appropriately.
Re:The C++ standard for the F-35 Fighter Jet [video] by repelsteeltje on Monday December 08, 2025 @04:48AM (#46190374)
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] by tatjam on Monday December 08, 2025 @09:27AM (#46192580)
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<u8, MAX_BUFFER_SIZE>, 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] by repelsteeltje on Monday December 08, 2025 @12:35PM (#46195150)
Okay, fair enough.

So it's mostly about the absence of abstraction, in the C example? C++ would offer the same convenience (with std::mutex and std::array globals), but in C it's more of a hassle. Gotcha.

One more question because I'm curious - where would you anticipate C would be able to squeeze out more performance in above example?