Many of these feel like throwing the baby out with the bathwater, where, out of fear of misuse, tools are thrown away.
For example, while `std::string` does have issues, number of allocations more indicative of poor usage than an issue with the class itself.
Other design choices are fine per se, but the reasons given are strange:
> And, since we don’t use classes or inheritance, we don’t have any need for RTTI.
> It also has another benefit; since all data is already verified to be ok by the data pipeline, you don’t need C++ exceptions in the engine.
Tons of projects (Chrome and Firefox to name two) build without RTTI or exceptions, but with extensive classes, extensive inheritance, and extraordinarily extensive validation code.
Many of these issues may be due to the age of the project, as much of the thinking seems, indeed, to be stuck about 10 years in the past. It does not match my experience with modern C++ in similar fields.
Std::string half of all allocations in the Chrome browser process (2014) [0]
The key difference is that web browsers support a highly arbitrary and mutable dataset. A game engine's assets exist in a mostly-static space. The things that are allocated at runtime are things that should have a known maximum, because going over that maximum will start to overrun latency targets. Many assets are streamed, but still hit a certain size and bandwidth budget, and so are still "basically static" - some degree of compilation and configuration at runtime always takes place for rendering features. The genuinely mutable part of game state while playing is in a comparatively confined space, and that allows a lot to be pushed to build time, where it's easier to validate and to maintain.
The features that change this picture are editors and arbitrary data imports. Web browsers are all about these two things. When you click a link the document may load thousands of gigantic images, and I might try to copy-paste the entire contents of Wikipedia into a text box. The engineering requirements are much broader as a consequence, and there are more rationales to need genuine "black box" interfaces supporting a complex protocol, as opposed to a static "calling function switches on a specified enum" approach, which is sufficient for almost every dynamic behavior encountered in game engines.
For example, while `std::string` does have issues, number of allocations more indicative of poor usage than an issue with the class itself.
Other design choices are fine per se, but the reasons given are strange:
> And, since we don’t use classes or inheritance, we don’t have any need for RTTI.
> It also has another benefit; since all data is already verified to be ok by the data pipeline, you don’t need C++ exceptions in the engine.
Tons of projects (Chrome and Firefox to name two) build without RTTI or exceptions, but with extensive classes, extensive inheritance, and extraordinarily extensive validation code.
Many of these issues may be due to the age of the project, as much of the thinking seems, indeed, to be stuck about 10 years in the past. It does not match my experience with modern C++ in similar fields.