On Sun, Jul 05, 2009 at 07:58:49PM -0500, Zachary Turner wrote:
I was wondering from a design perspective, why was it decided that intrusive_ptr should rely on user-defined free functions intrusive_ptr_add_ref and intrusive_ptr_release to handle the reference counting?
One of the main reasons for intrusive_ptr is to have smart pointers to third-party classes that already have their own refcount. Since you can't add a member to a class you don't control, using member functions to manipulate the refcount would rule out that use. The expectation in this case would be that the user would write these two free functions to just call the appropriate member functions on the third-party class.
This makes it somewhat inconvenient, for some constant type T, to support having two different instances of intrusive_ptr<T>, each of which use a different reference counting strategy.
If there's a clever way to allow this that I'm missing please advise.
I must admit, I'm not really sure what you are trying to achieve. It sounds like you have some instances of T, and you want some of them to store their reference count in some way, and the rest to have a completely unrelated way of storing their reference count. But if this is the case, it sounds like you actually have two different types, and Scott's solution sounds right; and even so, I don't know what you hope to achieve by that. -- "It must be accepted as a principle that the rifle, effective as it is, cannot replace the effect produced by the speed of the horse, the magnetism of the charge, and the terror of cold steel." -- British Cavalry training manual, 1907 ::: http://surreal.istic.org/