Question

Generally I follow the Google style guide, which I feel aligns nicely with the way I see things. I also, almost exclusively, use boost::scoped_ptr so that only a single manager has ownership of a particular object. I then pass around naked pointers, the idea being that my projects are structured such that the managers of said objects are always destroyed after the objects that use them are destroyed.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Smart_Pointers

This is all great, however I was just bitten by a nasty little memory stomp bug where the owner just so happened to be deleted before objects that were using it were deleted.

Now, before everyone jumps up and down that I’m a fool for this pattern, why don’t I just use shared_ptr ? etc., consider the point that I don’t want to have undefined owner semantics. Although shared_ptr would have caught this particular case, it sends the wrong message to users of the system. It says, “I don’t know who owns this, it could be you!”

What would have helped me would have been a weak pointer to a scoped pointer. In effect, a scoped pointer that has a list of weak references, that are nulled out when the scoped pointer destructs. This would allow single ownership semantics, but give the using objects a chance to catch the issue I ran into.

So at the expense of an extra ‘weak_refs’ pointer for the scoped_ptr and an extra pointer for the ‘next_weak_ptr’ in the weak_ptr, it would make a neat little single owner, multiple user structure.

It could maybe even just be a debug feature, so in ‘release’ the whole system just turns back into a normally sized scoped_ptr and a standard single pointer for the weak reference.

So….. my QUESTIONS after all of this are:

1. Is there such a pointer/patten already in stl/boost that I’m
   missing, or should I just roll my own?
2. Is there a better way, that
   still meets my single ownership goal?

Cheers,
Shane

Answer 1

 2. Is there a better way, that still meets my single ownership goal?

Do use a shared_ptr, but as a class member so that it’s part of the invariant of that class and the public interface only exposes a way to obtain a weak_ptr.

Of course, pathological code can then retain their own shared_ptr from that weak_ptr for as long as they want. I don’t recommend trying to protect against Machiavelli here, only against Murphy (using Sutter’s words). On the other hand, if your use case is asynchronous, then the fact that locking a weak_ptr returns a shared_ptr may be a feature!