| > 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. |
The standard hammer you would apply to enforce the synchronization in all cases is relational integrity, which is too expensive for a game's runtime environment. You don't always want to synchronize everything all of the time if you want to hit a high framerate target, and a lot of performance features boil down to relaxations on when synchronization occurs. Much of the detailed design in writing a game main loop is in dealing with the many consequences of supporting that.
That's why their recommendations on errors also refer to the earlier build process and Lua integration; by the time the data hits the inner loops of the engine, there shouldn't be a case where it's invalid, because if it is, then you can't have the optimized version either.