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.
> Someone once told me that pointers are dangerous, and I frankly don’t understand that.
Lack of ownership is one of the dangerous things. As, I see on the article itself “Not only that each weak_ptr.lock() was very expensive, it was also symptom of unclear ownership of the data.”
Smart pointers are good at declaring memory ownership.
> All those tiny allocations that the stl containers made, were like a death by a thousand needles.
A possible solution is the use of custom allocators.
> until they were replaced with something more fitting for the tasks.
This comment is key. Too often I have seen C++ developers critical of classes, STL, and other C++ features because engine Y or Z does not use them when are actually the best option for a particular project.
I appreciate that the comment is present.
> Often you hear people say that writing your own containers would introduce bugs, and that you should stick with stl. I find this problematic, since this is coming from engineers that should know quite well how to write an array/hashtable container.
But, this is quite a stupid comment. E.g : https://forum.defold.com/t/scaling-collision-object-when-gam...
That children objects need to scale with its parent is something that all engines do, but, I have had to fix this kind of scaling in the past in a custom version of the Irrlicht engine.
Should engineers know better. Maybe, but good engineers understand that errors may happen and put the needed measures to avoid or mitigate them. A useful one is to use already proven code.
Was an error in their custom made containers what caused the error in scaling when looping over the object children? We will never know.