Re: [boost] intrusive_ptr design question

Subject: Re: [boost] intrusive_ptr design question
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-07-06 10:53:20

On Mon, Jul 6, 2009 at 9:23 AM, Frank Mori Hess<frank.hess_at_[hidden]> 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.