So I’ve spent the past 3 days scratching and attempting to handle dangling pointers for GameObjects with unexpected life times… Every idea I’ve attempted is stumped under the fact that a pointer is scalar type, so it cannot have its behaviour changed. A pointer can be copied, I cannot stop that.
I have attempted keeping of all pointers created and clearing them, but the pointers can still have copies made, so if one of the pointers is by chance not referenced, then it can continue to be copied and refer to unintialised data.
I have attempted only returning a reference to a container object, and blocking its assignment operator. But that doesn’t stop copies from being able to have their own copy of a pointer. It did solve unified instancing though, and allowed the -> operator to be overloaded to hide the underlying GameObjectInstance class, abstracting away the GameObject container.
The last idea I have to attempt, is to include all necessary operator overloads to abstract away the container, and to make it point to a factory list, that is used to store all instances. The instances are returned by reference, so they cannot be copied. The == operator will be overloaded to allow for checking if it is null by querying the factory. Either this, or to revert to my first intrigue of making an entity component based system via structs with IDs, and the container objects just point to their struct data in the factory list.
This has given me a bit of a frustrating problem, but it’s one I’m excited to solve. Mimicking the Unity engine’s component architecture in C++ is one of the things I’ve wanted to try doing. It might end up poorly implemented by me, but I still am having fun. The learning experience is the best part, I’m delving into class interfacing via operators, and serious pointer issues with wrangling up dangling pointers.