C ++如何确保通过共享指针回收内存

Question

I am using boost shared pointers and these pointers are really shared all over the application. There are conditions, where such a shared pointer becomes invalid. For example, a shared pointer to a network resource, that can become invalid because network became unavailable. In such a scenario, where the shared pointer becomes invalid, i would like all objects to stop using it. How can i send a message to all objects that the pointer is invalid. If it was a normal pointer, i could set it to null and all client code should be checking for null pointer before using it. But, in case of a shared pointer, which keeps reference count, how can i achieve similar functionality ?

Answer 1

You can use weak pointers. That is, the code that handles the network events has the shared_ptr<Res> while everybody else has a weak_ptr<Res> . Now,

• when the resource becomes unavailable, just reset the shared_ptr to NULL ;
• when a client wants to use the resource, call lock() into the weak_ptr and test whether the returned shared_ptr is valid before using.

Answer 2

If it was a normal pointer, i could set it to null and all client code should be checking for null pointer before using it.

I doubt that. You'd then have copies of that raw pointer that point to invalid objects. You'd think that would solve the problem, but it doesn't . It amplifies it.

The fact is that the shared pointer itself doesn't become invalid, the object it contains does. So, logically, whether it's still safe to use it should be contained in the object, not the shared pointer.

a shared pointer to a network resource, that can become invalid because network became unavailable.

Just throw an exception when you attempt to call a method that attempts to use the network...

Answer 3

You need to store more information. You could put the resource together with a bool in a tuple, or you could use boost::optional , and set it to none when you want to invalidate it.

Answer 4

You almost certainly shouldn't be using shared pointer for this, since its semantics don't correspond to what you need. Shared pointer implements a sort of poor man's garbage collection, where the object ceases to exist when there are no more pointers to it; you need the opposite, that the pointers to the object cease to exist when there is no more object. (A reverse garbage collection, so to speak.)

I've used a ManagedPtr in the past; the pointer registers itself with the object, which must derive from a ManagingObj class which sets the pointers to null in its destructor. This works sometimes, but it still doesn't remove entries from lists, etc. where the other objects may be keeping it. And in practice, other objects which know about your network resource object may want to take specific actions when it disappears. In the end, you almost always need to use the observer pattern: any object which acquires a pointer to your object registers with it to be notified in case of its demise.

Answer 5

I would be inclined to follow the pattern used by standard streams: have an object that represents the resource, which can enter an error state and/or throw an exception when it detects (or is informed) that the network is no longer available. If you can't change the existing resource class, then this new object can hold the existing resource object (that currently all your users have shared pointers to), and the users can share the new object.

Unless you need all the users of this resource to respond promptly when it becomes unavailable, there doesn't seem any point trying to propagate a message to them all. If you just want them to stop using it, they can do that the next time they try to use it, and discover that it doesn't work any more. If they do really need a message, then write something to keep a list of them all, and call some function on them when the event that they're interested in occurs. This is called the Observer pattern or "listeners", and armed with those search terms you can find implementations and alternatives.

Ideally, users should be able to check for the error state either as part of using the resource, or immediately afterwards. Testing before use is usually error-prone, since it creates a window in which the network perhaps could become unavailable after the test but before it's used. Once your code has to handle that case correctly you might as well make it the only case, by not bothering to check in advance.