New answers tagged

1

One possible solution could be to use weak_ptr. A weak_ptr is like a shared_ptr, except it doesn't keep the object alive. If there are no shared_ptrs pointing to the object, it will be deleted, and then any weak_ptrs will hold NULL. You can use the lock method to get a shared_ptr from a weak_ptr. Example use: shared_ptr<Thingy> s = ...


7

At the moment I'm using std::shared_ptr to support multiple ownership of GameObjects so that they are held by both the scene and any other GameObjects within the game Don't do that. shared_ptr is often the wrong tool for the job, and that certainly applies here. Remember that smart pointers are for managing ownership; shared_ptr is about sharing ...


2

I see a couple of options: Have the Scene refuse to destroy a GameObject if the ref_count of it's shared_ptr is more than 1. This will oblige your users to take a great care of what happens. This might not be very fun or practical, though. In your GameObject architecture, add a listener pattern: when GameObject A links to GameObject B, tell B that A is ...



Top 50 recent answers are included