On Mon, Jul 6, 2009 at 9:23 AM, Frank Mori Hess<frank.hess@nist.gov> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 06 July 2009, Zachary Turner wrote:
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.
But why not just allow the intrusive_ptr to accept those free functions as constructor arguments, allowing me to pass different free functions for different instances?
Because you'd have to store 2 function pointers in every intrusive_ptr object? Why don't you just store the function pointers in your class? Then for example intrusive_ptr_add_ref can call some member function of your class, which in turn calls its object's internal function pointer.
You shouldn't have to store 2 function pointers for every intrusive_ptr object. You should only have to store 2 function pointers per instance pointed to, and then 1 reference to some shared structure in each intrusive_ptr object. Much like shared_ptr currently does. Also, maybe the object is part of some library that I didn't write, but I still want to provide reference counting for it through some mechanism other than that which is provided by shared_ptr.