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.

Google style bans them: https://google.github.io/styleguide/cppguide.html#Exceptions

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

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.

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.

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.

Large parts of the standard library malloc/free.

What industry do you work in? Modern RAII practices are pretty prevalent

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.

Thinking recursively is one thing, but can't remember the last time I've wanted to use recursion in real code.

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.

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.

Semi serious idea: A lot of people (including me) write C++ but it's basically C plus a small set of really ergonomic and useful C++ features (eg references). This should be standardised as a new language called C+

For a long time, at least in MS and Intel, the C++ compilers were better than the C compilers.

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

Re: recursion. She explains in her video. Per requirements, the stack capacity has to be statically verifiable, and not dependent on runtime input.