On Wed, Jul 8, 2009 at 8:21 PM, Ulrich Eckhardt <doomster@knuut.de> wrote:
On Monday 06 July 2009 17:23:41 Zachary Turner wrote:
Is there a case to be made for a more flexible shared_ptr (either through modification or through a new class addition) that allows one to provide custom reference counting semantics much the same way that shared_ptr allows one to provide custom deletion semantics?
Maybe it's already there: shared_ptr doesn't care if the passed deleter actually deletes anything. If you now take an object with an existing reference count, you just increment that count and pass the function that decrements it as deleter function to a shared_ptr constructor. This creates a parallel reference count, but it should be safe. Nothing can pull the object from under the shared_ptr's feet because it holds a reference. The shared_ptr doesn't destroy the object either, at most it decrements the reference count.
It isn't already there, because unfortunately, in general, this doesn't work. You need the reference count to increase when the shared pointer is copied, for example. I am of the opinion that this isn't a problem we should solve. Inherently mixing lifetime idioms on a single object instance is dangerous. Interoperation with shared_ptr does not make semantic sense. The only working scenario I can imagine is one where the shared_ptr would behave exactly like the intrusive_ptr. As others have indicated this would increase the memory footprint of shared_ptr since any customisable functor for the reference count increment / decrement would need to a have a reference to the count. Hence I have yet to see a convincing case where the design of such interoperation would be the optimal design, and the implementation overhead does not obey the zero overhead principle.
Uli
Regards, Neil Groves