[HN Gopher] The C++ standard for the F-35 Fighter Jet [video]
___________________________________________________________________
The C++ standard for the F-35 Fighter Jet [video]
PDF: https://www.stroustrup.com/JSF-AV-rules.pdf
Author : AareyBaba
Score : 135 points
Date : 2025-12-07 18:07 UTC (4 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| mwkaufma wrote:
| TL;DR
|
| - no exceptions
|
| - no recursion
|
| - no malloc()/free() in the inner-loop
| jandrewrogers wrote:
| i.e. standard practice for every C++ code base I've ever worked
| on
| DashAnimal wrote:
| What industry do you work in? Modern RAII practices are
| pretty prevalent
| jandrewrogers wrote:
| What does RAII have to do with any of the above?
| WD-42 wrote:
| 0 allocations after the program initializes.
| nicoburns wrote:
| RAII doesn't necessarily require allocation?
| Gupie wrote:
| Open a file in the constructor, close it in the
| destructor. RAII with 0 allocations.
| tialaramex wrote:
| RAII doesn't imply allocating.
|
| My guess is that you're assuming all user defined types,
| and maybe even all non-trivial built-in types too, are
| boxed, meaning they're allocated on the heap when we
| create them.
|
| That's not the case in C++ (the language in question
| here) and it's rarely the case in other modern languages
| because it has terrible performance qualities.
| jjmarr wrote:
| Stack "allocations" are basically free.
| nmhancoc wrote:
| Not an expert but I'm pretty sure no exceptions means you
| can't use significant parts of std algorithm or the std
| containers.
|
| And if you're using pooling I think RAII gets
| significantly trickier to do.
| theICEBeardk wrote:
| https://en.cppreference.com/w/cpp/freestanding.html to
| see the parts you can use.
| DashAnimal wrote:
| Well if you're using the standard library then you're not
| really paying attention to allocations and deallocations
| for one. For instance, the use of std::string. So I guess
| I'm wondering if you work in an industry that avoids std?
| jandrewrogers wrote:
| I work in high-scale data infrastructure. It is common
| practice to do no memory allocation after bootstrap. Much
| of the standard library is still available despite this,
| though there are other reasons to not use the standard
| containers. For example, it is common to need containers
| that can be paged to storage across process boundaries.
|
| C++ is designed to make this pretty easy.
| astrobe_ wrote:
| And what does "modern" has to do with it anyway.
| Cyan488 wrote:
| This is common in embedded systems, where there is limited
| memory and no OS to run garbage collection.
| wiseowise wrote:
| That's hardly 90% of C++.
| bluGill wrote:
| Large parts of the standard library malloc/free.
| canyp wrote:
| Or throw.
| gmueckl wrote:
| But you won't miss those parts much if all your memory is
| statically initialized at boot.
| elteto wrote:
| If you compile with -fno-exceptions you just lost almost all
| of the STL.
|
| You can compile with exceptions enabled, use the STL, but
| strictly enforce no allocations after initialization. It
| depends on how strict is the spec you are trying to hit.
| vodou wrote:
| Not my experience. I work with a -fno-exceptions codebase.
| Still quite a lot of std left. (Exceptions come with a
| surprisingly hefty binary size cost.)
| theICEBeardk wrote:
| Apparently according to some ACCU and CPPCon talks by
| Khalil Estel this can be largely mitigated even in
| embedded lowering the size cost by orders of magnitude.
| Espressosaurus wrote:
| Yeah. I unfortunately moved to an APU where code size
| isn't an issue so I never got the chance to see how well
| that analysis translated to the work I do.
|
| Provocative talk though, it upends one of the pillars of
| deeply embedded programming, at least from a size
| perspective.
| vodou wrote:
| Need to check it out. I guess you mean these:
|
| - C++ Exceptions Reduce Firmware Code Size, ACCU [1]
|
| - C++ Exceptions for Smaller Firmware, CppCon [2]
|
| [1]: https://www.youtube.com/watch?v=BGmzMuSDt-Y
|
| [2]: https://www.youtube.com/watch?v=bY2FlayomlE
| elteto wrote:
| Not exactly sure what your experience is, but if you work
| with in an -fno-exceptions codebase then you know that
| STL containers are not usable in that regime (with the
| exception of std::tuple it seems, see freestanding
| comment below). I would argue that the majority of use
| cases of the STL is for its containers.
|
| So, what exact parts of the STL do you use in your code
| base? Most be mostly compile time stuff (types, type
| trait, etc).
| alchemio wrote:
| You can use std containers in a no-exceptions
| environment. Just know that if an error occurs the
| program will terminate.
| theICEBeardk wrote:
| Are you aware of the Freestanding definition of STL? See
| here: https://en.cppreference.com/w/cpp/freestanding.html
| Large and useful parts of it are available if you run with
| a newer c++ standard.
| elteto wrote:
| Well, it's mostly type definitions and compiler stuff,
| like type_traits. Although I'm pleasantly surprised that
| std::tuple is fully supported. It looks like C++26 will
| bring in a lot more support for freestanding stuff.
|
| No algorithms or containers, which to me is probably 90%
| of what is most heavily used of the STL.
| Taniwha wrote:
| yup, same for any real time code, new/malloc/free/delete use
| hidden mutexes and can cause priority inversion as a result -
| heisenbugs, that audio/video dropout that happens rarely and
| you can't quite catch - best to code to avoid them
| AnimalMuppet wrote:
| They also can simply fail, if you are out of memory or your
| heap is hopelessly fragmented. And they take an unpredictable
| amount of time. That's very bad if you're trying to _prove_
| that you satisfy the worst-case timing requirement.
| thefourthchime wrote:
| I've worked on a playout system for broadcast television. The
| software has to run for years at a time and not have any leaks,
| We need to send out one frame of television exactly on time,
| every time.
|
| It is "C++", but we also follow the same standards. Static
| memory allocation, no exceptions, no recursion. We don't use
| templates. We barely use inheritance. It's more like C with
| classes.
| EliRivers wrote:
| I worked on the same for many years; same deal - playout
| system for broadcast, years of uptime, never miss a frame.
|
| The C++ was atrocious. Home-made reference counting that was
| thread-dangerous, but depending on what kind of object the
| multi-multi-multi diamond inheritance would use, sometimes it
| would increment, sometimes it wouldn't. Entire objects made
| out of weird inheritance chains. Even the naming system was
| crazy; "pencilFactory" wasn't a factory for making pencils,
| it was anything that was made by the factory for pencils.
| Inheritance rather than composition was very clearly the
| model; if some other object had function you needed, you
| would inherit from that also. Which led to some object
| inheriting from the same class a half-dozen times in all.
|
| The multi-inheritance system given weird control by objects
| on creation defining what kind of objects (from the set of
| all kinds that they actually were) they could be cast to via
| a special function, but any time someone wanted one that
| wasn't on that list they'd just cast to it using C++ anyway.
| You had to cast, because the functions were all deliberately
| private - to force you to cast. But not how C++ would expect
| you to cast, oh no!
|
| Crazy, home made containers that were like Win32 opaque
| objects; you'd just get a void pointer to the object you
| wanted, and to get the next one pass that void pointer back
| in. Obviously trying to copy MS COM with IUnknown and other
| such home made QueryInterface nonsense, in effect creating
| their own inheritance system on top of C++.
|
| What I really learned is that it's possible to create systems
| that maintain years of uptime and keep their frame accuracy
| even with the most atrocious, utterly insane architecture
| decisions that make it so clear the original architect was
| thinking in C the whole time and using C++ to build his own
| terrible implementation of C++, and THAT'S what he wrote it
| all in.
|
| Gosh, this was a fun walk down memory lane.
| webdevver wrote:
| it is also interesting that places where you would expect
| to have quite 'switched-on' software development practices
| tend to be the opposite - and the much-maligned
| 'codemonkeys' at 'big tech' infact tend to be pretty damn
| good.
|
| it was painful for me to accept that the most elite
| programmers i have ever encountered were the ones working
| in high frequency trading, finance, and mass-producers of
| 'slop' (adtech, etc.)
|
| i still ache to work in embedded fields, in 8kB constrained
| environment to write perfectly correct code without a cycle
| wasted, but i know from (others) experience that embedded
| software tends to have the worst software developers and
| software development practices of them all.
| uecker wrote:
| 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.
| tialaramex wrote:
| Forbidding recursion is pretty annoying. One of the nice things
| that's on the distant horizon for Rust is an explicit tail
| recursion operator perhaps named `become`. Unlike naive
| recursion, which as this video (I haven't followed the link but
| I'm assuming it is Laurie's recent video) explains risks stack
| overflow, optimized tail recursion doesn't grow the stack.
|
| The idea of `become` is to signal "I believe this _can_ be tail
| recursive " and then the compiler is either going to agree and
| deliver the optimized machine code, or disagree and your
| program won't compile, so in neither case have you introduced a
| stack overflow.
|
| Rust's Drop mechanism throws a small spanner into this, in
| principle if every function foo makes a Goose, and then in most
| cases calls foo again, we shouldn't Drop each Goose until the
| functions return, which is too late, that's now our tail
| instead of the call. So the `become` feature AIUI will spot
| this, and Drop that Goose early (or refuse to compile) to
| support the optimization.
| tgv wrote:
| In C, tail recursion is a fairly simple rewrite. I can't
| think of any complications.
|
| But ... that rewrite can increase the cyclomatic complexity
| of the code on which they have some hard limits, so perhaps
| that's why it isn't allowed? And the stack overflow, of
| course.
| AnimalMuppet wrote:
| I don't know that it's just cyclomatic complexity. I think
| it at least part of it is proving that you meet hard real-
| time constraints. Recursion is harder to analyze that way
| than "for (i = 0; i < 16; i++) ... " is.
| zozbot234 wrote:
| The tail recursion operator is a nice idea, but the extra
| `become` keyword is annoying. I think the syntax should be
| `return as`: it uses existing keywords, is unambiguous and
| starts with `return` which tail recursion is a special case
| of.
| tialaramex wrote:
| Traditionally the time for bike shedding the exact syntax
| is much closer to stabilization.
|
| Because Rust is allowed (at this sort of distance in time)
| to reserve new keywords via editions, it's not a problem to
| invent more, so I generally do prefer new keywords over re-
| using existing words but I'm sure I'd be interested in
| reading the pros and cons.
| zozbot234 wrote:
| The usual argument against a decorated `return` keyword
| is that a proper tail call is not a true "return" since
| it has to first drop any locals that aren't passed thru
| to the tail call. I don't think it's a very good argument
| because if the distinction of where exactly those
| implicit drops occur was that important, we'd probably
| choose to require explicit drops anyway.
| krashidov wrote:
| Has anyone else here banned exceptions (for the most part) in
| less critical settings (like a web app)?
|
| I feel like that's the way to go since you don't obscure
| control flow. I have also been considered adding assertions
| like TigerBeetle does
|
| https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...
| mwkaufma wrote:
| Lots of games, and notably the Unreal Engine, compile without
| exceptions. EASTL back in the day was in part written to
| avoid the poor no-exception support in Dinkumware STL and
| STLport.
| tonfa wrote:
| Google style bans them:
| https://google.github.io/styleguide/cppguide.html#Exceptions
| fweimer wrote:
| Most large open-source projects ban exceptions, often because
| the project was originally converted from C and is just not
| compatible with non-local control flow. Or the project
| originated within an organization which has tons of C++ code
| that is not exception-safe and is expected to integrate with
| that.
|
| Some large commercial software systems use C++ exceptions,
| though.
|
| Until recently, pretty much all implementations seemed to
| have a global mutex on the throw path. With higher and higher
| core counts, the affordable throw rate in a process was
| getting surprisingly slow. But the lock is gone in
| GCC/libstdc++ with glibc. Hopefully the other implementations
| follow, so that we don't end up with yet another error
| handling scheme for C++.
| msla wrote:
| At that point, why not write in C? Do they think it's C/C++ and
| not understand the difference?
|
| > no recursion
|
| Does this actually mean no recursion or does it just mean to
| limit stack use? Because processing a tree, for example, is
| recursive even if you use an array, for example, instead of the
| stack to keep track of your progress. The real trick is
| limiting memory consumption, which requires limiting input
| size.
| mwkaufma wrote:
| For a long time, at least in MS and Intel, the C++ compilers
| were better than the C compilers.
| mwkaufma wrote:
| Re: recursion. She explains in her video. Per requirements,
| the stack capacity has to be statically verifiable, and not
| dependent on runtime input.
| drnick1 wrote:
| You may still want to use classes (where they make sense),
| references (cleaner syntax than pointers), operator
| overloading, etc. For example, a linear algebra library is
| far nicer to write and use in C++.
| pton_xd wrote:
| That's standard in the games industry as well. Plus many others
| like no rtti, no huge dependencies like boost, no smart
| pointers, generally avoid ctors / dtors, etc.
| petermcneeley wrote:
| This is basically video games prior to 2010
| mwkaufma wrote:
| Relax the dynamic-memory restriction to "limit per-event
| memory allocation to the bump allocator" and it's still
| mostly true for many AAA/AAAA games I work on today.
| barfoure wrote:
| Do avionics in general subscribe to MISRA C/C++ or do they go
| even further with an additional (or different) approach?
| fallingmeat wrote:
| coding standard is a part of the story. mainly it comes down to
| level of rigor and documenting process and outcomes for audit
| ability. DO-178c
| 4gotunameagain wrote:
| Depends on the region. MISRA is widely adopted, and then there
| are the US MIL standards, ECSS for european aerospace stuff,
| do-178C for aviation..
| stackghost wrote:
| 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.
| garyfirestorm wrote:
| You're joking right? That autogenerated code is generally
| garbage and spaghetti code. It was probably the reason for
| Toyotas unintended acceleration glitch.
| vodou wrote:
| Modern autogenerated C code from Simulink is rather
| effective. It is neither garbage nor spaghetti, it is
| just... peculiar.
| addaon wrote:
| It's also much, much more resource intensive (both
| compute and memory) than what a human would right for the
| same requirements.
| stackghost wrote:
| For control systems like avionics it either passes the
| suite of tests for certification, or it doesn't. Whether
| a human could write code that uses less memory is simply
| not important. In the event the autocode isn't performant
| enough to run on the box you just spec a faster chip or
| more memory.
| addaon wrote:
| I'm sorry, but I disagree. Building these real-time
| safety-critical systems is what I do for a living. Once
| the system is designed and hardware is selected, I agree
| that if the required tasks fit in the hardware, it's good
| to go -- there's no bonus points for leaving memory
| empty. But the sizing of the system, and even the
| decomposition of the system to multiple ECUs and the
| level of integration, depends on how efficient the code
| is. And there are step functions here -- even a decade
| ago it wasn't possible to get safety processors with
| sufficient performance for eVTOL control loops (there's
| no "just spec a faster chip"), so the system design
| needed to deal with lower-ASIL capable hardware and
| achieve reliability, at the cost of system complexity, at
| a higher level. Today doing that in a safety processors
| is possible for hand-written code, but still marginal for
| autogen code, meaning that if you want to allow for the
| bloat of code gen you'll pay for it at the system level.
| AnimalMuppet wrote:
| > It was probably the reason for Toyotas unintended
| acceleration glitch.
|
| Do you have any evidence for "probably"?
| garyfirestorm wrote:
| I know for the fact simulink generates spaghetti and
| spaghetti code was partially blamed for Toyotas problems.
| Hence the inference
|
| See https://www.safetyresearch.net/toyota-unintended-
| acceleratio...
| CamouflagedKiwi wrote:
| That's a nonsensical connection. "Spaghetti code" is a
| very general term, that's nowhere near specific enough
| for the two to be related.
|
| "I know for a fact that Italian cooks generate spaghetti,
| and the deceased's last meal contained spaghetti,
| therefore an Italian chef must have poisoned him"
| stackghost wrote:
| SRS is a for-profit corporation whose income comes from
| lawsuits, so their reports/investigations are tainted by
| their financial incentive to overstate the significance
| of their findings.
| stackghost wrote:
| No I'm not joking at all. The Autocode feature generates
| code that has high fidelity to the model in simulink, and
| is immensely more reliable than a human.
|
| It is impossible for a simulink model to accidentally type
| `i > 0` when they meant `i >= 0`, for example. Any human
| who tells you they have not made this mistake is a liar.
|
| Unless there was a second uncommanded acceleration problem
| with Toyotas, my understanding is that it was caused by
| poor mechanical design of the accelerator pedal that caused
| it to get stuck on floor mats.
|
| In any case, when we're talking about safety critical
| control systems like avionics, it's better to abstract away
| the actual act of typing code into an editor, because it
| eliminates a potential source of errors. You verify the
| model at a higher level, and the code is produced in a
| deterministic manner.
| fl7305 wrote:
| > It is impossible for a simulink model to accidentally
| type `i > 0` when they meant `i >= 0`
|
| The Simulink Coder tool is a piece of software. It is
| designed and implemented by humans. It will have bugs.
|
| Autogenerated code is different from human written code.
| It hits soft spots in the C/C++ compilers.
|
| For example, autogenerated code can have really huge
| switch statements. You know, larger than the 15-bit
| branch offset the compiler implementer thought was big
| enough to handle any switch-statement any sane human
| would ever write? So now the switch jumps backwards
| instead when trying to get the the correct case-
| statement.
|
| I'm not saying that Simulink Coder + a C/C++ compiler is
| bad. It might be better than the "manual coding" options
| available. But it's not 100% bug free either.
| cpgxiii wrote:
| 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 complexity by hand.
| fluorinerocket wrote:
| Rockets have flown to orbit on auto coded simulink, seen it
| myself
| jandrewrogers wrote:
| For those interested, the F-35 (nee Joint Strike Fighter) C++
| coding standards can be found here, all 142 pages of it:
|
| https://www.stroustrup.com/JSF-AV-rules.pdf
| tgv wrote:
| From quickly glancing over a couple of pages, that looks
| sensible. Which makes me curious to see some exceptions to the
| "shall" rules. With a project of this size, that should give
| some idea about the usefulness of such standards.
| extraduder_ire wrote:
| The first time I came across this document, someone was using
| it as an example how the c++ you write for an Arduino Uno is
| still c++ despite missing so many features.
| msla wrote:
| Interesting they're using C++ as opposed to Ada.
| WD-42 wrote:
| The video goes into the history of why the military
| eventually accepted c++ instead of enforcing Ada.
| raffael_de wrote:
| Interesting font choice for the code snippets. I wonder if
| that's been chosen on a whim or if there is a reason for not
| going with mono space.
| shepherdjerred wrote:
| I wonder if they use static analysis to enforce these rules, or
| if developers are expected to just know all of this
| ibejoeb wrote:
| static analysis
| genewitch wrote:
| In general, are these good recommendations for building
| software for embedded or lower-spec devices? I don't know how
| to do preprocessor macros anyhow, for instance - so as i am
| reading this i am like "yeah, i agree..." until the no stdio.h!
| GoblinSlayer wrote:
| stdio.h is not what you would use in safe code.
| nikanj wrote:
| In 1994 C++ compilers were buggy, and a modernization of the C++
| allowed features list is still stuck in a committee somewhere?
| thenobsta wrote:
| I wonder how these compare to high frequency training standards.
| It seems like they'd have similar
| speed/reliability/predictability requirements in the critical
| paths.
| perbu wrote:
| JFS-CPP bans exceptions because you would lose control over the
| execution of the problem. The HFT crowds didn't like it because
| you'd add 10ns to a function call.
|
| At least before we had zero-cost exceptions. These days, I
| suspect the HFT crowd is back to counting microseconds or
| milliseconds as trades are being done smarter, not faster.
| clanky wrote:
| There are at least some HFT players who actually use exceptions
| to avoid branches on the infrequent-but-speed-critical
| execution path:
| https://youtu.be/KHlI5NBbIPY?si=VjFs7xVN0GsectHr
| ltbarcly3 wrote:
| Paging our Ada fanboys! You're missing it!
| semiinfinitely wrote:
| even with 90% of c++ features banned, the language remains ~5x
| larger than every other programming language
| pjmlp wrote:
| Check C# 10, Python 3.14, D, Haskell,...
| kaluga wrote:
| The "90% ban" isn't about hating C++ -- it's about guaranteeing
| determinism. In avionics, anything that can hide allocations, add
| unpredictable control flow, or complicate WCET analysis gets
| removed. Once you operate under those constraints, every language
| shrinks to a tiny, fully-auditable subset anyway.
| time4tea wrote:
| 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!
| msla wrote:
| Especially since there is a widely recognized way to ignore a
| parameter: (void) a;
|
| Every C programmer beyond weaning knows that.
| stefan_ wrote:
| I'm sure thats disallowed for the C-style cast.
| daringrain32781 wrote:
| C++17 has the [[maybe_unused]] attribute.
| cpgxiii wrote:
| Fwiw, unused-cast-to-void is a case that GCC and Clang
| ignore when using -Wno-old-style-cast, which is what most
| projects prohibiting C-style casts are going to be using
| (or whatever the equivalent their compiler provides).
| time4tea wrote:
| 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!
| addaon wrote:
| Sometimes. But sometimes you have a set of functions that
| are called through function pointers that need the same
| signature, and one or more of them ignore some of the
| arguments. These days I'd spell that
| __attribute__((unused)); but it's a perfectly reasonable
| case.
| unwind wrote:
| For C, the proper/expected/standard way to reference a variable
| without accessing it is a cast to void:
| (void) a;
|
| I'm sure there are commonly-implemented compiler extensions,
| but this is the normal/native way and should always work.
| amluto wrote:
| Not if you use GCC.
|
| https://godbolt.org/z/zYdc9ej88
|
| clang gets this right.
| comex wrote:
| It does work in GCC to suppress unused variable warnings.
| Just not for function calls I guess.
| Am4TIfIsER0ppos wrote:
| You've defined that function with an attribute saying not
| to ignore the returned value. Is it right to explicitly
| silence an explicit warning?
| MathMonkeyMan wrote:
| Sometimes. For example, you might be setting a non-
| crucial option on a socket, and if it fails you don't
| even care to log the fact (maybe the logging would be too
| expensive), so you just ignore the return value of
| whatever library is wrapping setsockopt.
| ivanjermakov wrote:
| Zig makes it explicit with _ = a;
|
| And you would encounter it quite often because unused variable
| is a compilation error:
| https://github.com/ziglang/zig/issues/335
| ErroneousBosh wrote:
| Golang is exactly the same.
|
| It's extremely annoying until it's suddenly very useful and
| has prevented you doing something unintended.
| bluecalm wrote:
| 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.
| bluecalm wrote:
| Doesn't it make it more likely unused variables stay in the
| codebase? You want to experiment, the code doesn't compile,
| you add this (probably by automatic tool), the code now
| compiles. You're happy with your experiment. As the compiler
| doesn't complain you commit and junk stays in the code.
|
| Isn't it just bad design that makes both experimenting harder
| and for unused variables to stay in the code in the final
| version?
| binary132 wrote:
| It's very weird how none of the sibling comments understood
| what it were saying is wrong with this.
| tialaramex wrote:
| 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 _twenty years_ before its author, Bjarne Stroustrup
| suddenly decides after years of insisting that C++ dialects are
| a terrible idea and will never be endorsed by the language
| committee, that in fact dialects (now named "profiles") are
| the magic ingredient to fix the festering problems with the
| language.
|
| While Laurie's video is fun, I too am sceptical about the value
| of style guides, which is what these are. "TABS shall be
| avoided" or "Letters in function names shall be lowercase"
| isn't because somebody's aeroplane fell out of the sky - it's
| due to using a style Bjarne doesn't like.
| writtiewrat wrote:
| If one limited C++ profiles to have no semantic effect and to
| not change code generation, only subsetting, they would be
| way simpler than dialects, right? More limited, yes, but also
| way simpler.
|
| It would enable preventing a lot of footguns, at the very
| least, like vector<bool>.
|
| Wait, you're one of those Rust evangelists, right? Have you
| been paid like fasterthanlime?
| geophph wrote:
| LaurieWired is an awesome follow on YouTube!
| jamal-kumar wrote:
| Her ARM assembly tutorial series is really excellent
| manoDev wrote:
| You mean fighters ARE coded in C++? My god
| GoblinSlayer wrote:
| "Launching nuclear rockets" just became literal.
| fweimer wrote:
| I think the late Robert Dewar once quipped that modern jet
| fighters aren't safety-critical applications because the
| aircraft disintegrates immediately if the computer system
| fails.
| anonymousiam wrote:
| 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 continue.
| Thaxll wrote:
| Can't this be done at runtime? Like the underlying calls can
| black list hardware address on read/write faults?
| amluto wrote:
| If you have memory to spare and are using hardware with an
| MMU, you can remap your logical address to a different page.
| Linux can do this, but only for user memory.
| anonymousiam wrote:
| This assumes that the operating system can run. If the
| memory corruption impacts the OS, then it may be impossible
| to recover. As the systems (and software) have become more
| complex, keeping these Mission Assurance best practices
| becomes more important, but the modern generation of
| developers sometimes loses sight of this.
|
| A good example of what I'm talking about is a program that
| I was peripherally involved with about 15 years ago. The
| lead wanted to abstract the mundane details from the users
| (on the ground), so they would just "register intent" with
| the spacecraft, and it would figure out how to do what was
| wanted. The lead also wanted to eliminate features such as
| "memory dump", which is critical to the anomaly resolution
| process. If I had been on that team, I would have raised
| hell, but I wasn't, and at the time, I needed that team
| lead as an ally.
| d-lisp wrote:
| Wow, but how did they deal with anomalies ?
|
| I mean, even when I have the codebase readily accessible
| and testable in front of my eyes, I never trust the tests
| to be enough ? I often spot forgotten edge cases and bugs
| of various sort in C/embedded projects BECAUSE I run the
| program, can debug and spot mem issues and whole a lot of
| other things for which you NEED to gather the most
| informations you can in order to find solutions ?
| dzonga wrote:
| I guess a bigger conversation could be had in regards to:
|
| what leads to better code in terms of understandability &
| preventing errors
|
| Exceptions (what almost every language does) or Error codes (like
| Golang)
|
| are there folks here that choose to use error codes and forgo
| Exceptions completely ?
| jandrewrogers wrote:
| There isn't much of a conversation to be had here. For low-
| level systems code, exceptions introduce a bunch of issues and
| ugly edge cases. Error codes are cleaner, faster, and easier to
| reason about in this context. Pretty much all systems languages
| use error codes.
|
| In C++, which supports both, exceptions are commonly disabled
| at compile-time for systems code. This is pretty idiomatic,
| I've never worked on a C++ code base that used exceptions. On
| the other hand, high-level non-systems C++ code may use
| exceptions.
| bri3d wrote:
| 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 then. It seems to me that the software field overall has
| become more open to a wider variety of languages and concepts,
| and knowing Ada wouldn't be perceived as widely as career
| pidgeonholing today. Plus, Ada is having a bit of a resurgence
| with stuff like NVidia picking SPARK.
| factorialboy wrote:
| Isn't the F35 program considered a failure? Or am I confusing it
| with some other program?
| TimorousBestie wrote:
| The research and development effort went way over budget, the
| first couple rounds of production were fraught with difficulty,
| and the platform itself has design issues from being a "one-
| size-fits-all" compromise (despite also having variants for
| each service).
|
| I haven't heard anything particularly bad about the software
| effort, other than the difficulties they had making the VR/AR
| helmet work (the component never made it to production afaik).
| themafia wrote:
| They oxygen delivery system fails and has left pilots
| hypoxic.
|
| https://www.nwfdailynews.com/story/news/local/2021/08/02/f-3.
| ..
|
| The electrical system performs poorly under short circuit
| conditions.
|
| https://breakingdefense.com/2024/10/marine-corps-reveals-
| wha...
|
| They haven't even finished delivering and now have to
| overhaul the entire fleet due to overheating.
|
| https://nationalsecurityjournal.org/the-f-35-fighters-2-big-.
| ..
|
| This program was a complete and total boondoggle. It was
| entirely the wrong thing to build in peace time. It was a
| moonshoot for no reason other than to mollify bored generals
| and greedy congresspeople.
| tsunagatta wrote:
| The F-35 was in development hell for a while for sure, but it's
| far from a failure. See the recent deals where it's been used
| as a political bargaining chip; it still ended up being a very
| desirable and capable platform from my understanding.
| fl7305 wrote:
| > See the recent deals where it's been used as a political
| bargaining chip; it still ended up being a very desirable and
| capable platform from my understanding.
|
| From a european perspective, I can tell you that the mood has
| shifted 180 degrees from "buy American fighters to solidify
| our ties with the US" to "can't rely on the US for anything
| which we'll need when the war comes".
| joha4270 wrote:
| A lot of people have made careers out of telling you that it's
| a failure, but while not everything about the F-35 is an
| unquestionable success, it has produced a "cheap" fighter jet
| that is more capable than all but a handful of other planes.
|
| Definitely not a failure.
| FpUser wrote:
| Her point about exceptions vs error codes was that one failed to
| catch exception of particular and and things went south meanwhile
| if we instead "catch" error code all will be nice and dandy. Well
| one might fail to handle error codes just as well.
|
| That is of course not to say that exceptions and error codes are
| the same.
| chairmansteve wrote:
| Ahhh. They use C++.....
|
| That explains all the delays on the F-35....,
___________________________________________________________________
(page generated 2025-12-07 23:00 UTC)