> I am a bit reluctant making RefCountedObject template/policy-based, as this will require major changes, including pulling a lot of code into header files, which I'd like to avoid.
> Not necessarily. While it's true that all current RefCountedObject code must go in header, that's not so much code. Non-breaking change can be done through typedef approach (see my other response
). The benefit, on the other side, is that we can provide an opportunity for alternative (e.g. lock-free) approaches like we recently did with SharedPtr.
But this does not save the problem if someone wants to change refcounting behavior for a subclass of Notification, which is a subclass of RefCountedObject. The only way here is through a virtual function. OTOH, making RefCountedObject policy based is probably a bit overshooting, because if you're using AutoPtr, AutoPtr does not require a RefCountedObject. It only needs an object with duplicate() and release() member functions.
> > What you'd like to achieve can be done in a way simpler way:
> > Change RefCountedObject in the following way:
> > 1. add a protected virtual member function
> > which, in the default implementation, simply calls delete this.
> Just out of curiosity: Provided one uses RefCountedObject (and not a subclass), should the virtual dispose() be inlined and not suffer the runtime redirection penalty due to it's "virtualness"?
In most cases, no. Only if the compiler can be really sure that there won't ever be a subclass of the class you're using. But the virtual call here does not cost that much, because it's only done once, before the object is destroyed. I would consider this premature optimization ;-)