I had this idea bout using shared_ptr to keep a single object alive while multiple pointers point to it, namely resource type objects like textures and sound effects and even ai scripts.
Imagine having a arcade shooter scene and you have a bunch of the same kind of vessel floating around. With shared_ptr they can all access the same resources, the sprite, the sound effects, etc, for that specific kind of vessel. Thats great, and thats what we want.
And when the last vessel of a particular kind is destroyed and we don't see another of that type for 5 minutes, then it is unloaded from memory. Thats fine too.
What if we are in a situation where we require a single pointer to particular resource and no more, intermittently over a period of time? For example if we have one vessel of a particular type that requires access to a particular set of resources, textures, sounds, etc, and we only ever have one in the scene at a time, but every time it is destroyed it respawns after a second or so. It would be wasteful to unload and reload it from memory over and over.
So in order to get around that we would want to tell the shared_ptr implementation to not delete the resource object when it hits a count of zero referring vessel objects (or preferably, to just increment the count by 1 and change nothing else). However, I cannot access the reference count directly in order to modify it-- its a private member of the shared_ptr implementation. The only recourse I can think of is to create "dummy" pointers that are only used to keep the count one higher than it would otherwise be, and therefore keep the resources in memory so that they do not need to be reloaded.
Seems ugly though. A person reading code who sees a pointer expects it to be used for something other than keeping the reference count of a shared pointer 1 higher than it would otherwise be. Is there a better way to do this that is no more complicated?
EDIT:
As I think about it though, if there are no references to the object how can i know how to dereference it in the first place? I guess the "dummy" pointer would really be a kind of codeless pointer factory.