Re: [boost] Re: Re: smart_ptr implementation descussion topics

From: Greg Colvin (greg_at_[hidden])
Date: 2002-05-07 17:36:16

At 02:05 PM 05/07/2002, you wrote:

>"Greg Colvin" <greg_at_[hidden]> wrote in message
>>    void com_releaser(IUnknown* p) { p->Release(); }
>>
>>    template<class T> shared_ptr<T>
>>    make_com_shared_ptr(IUnknown* p) {
>>       p->AddRef();
>>       return shared_ptr<T> (p,com_releaser);
>>    }
>We already talked about this.

Yes, we did.  That's why I was surprised to see COM come
up again. 

>I could(?) be acceptable for COM pointers. But
>for generic class with intrusive counter it does not have a sense. There
>could be a lot of reasons why one would not want to inherit from
>counted_base (performance is for once,existent code is second).

It makes whatever sense it makes -- you have to make a tradeoff
of speed, space, and binary compatibility.  If you choose not to
inherit from counted_base, and not to use a wrapper like that
above, then your shared_ptr won't be binary compatible with other
shared_ptrs that do.  So far we haven't seen anyway to get around
this fact.

>To Peter:
>
>I think that shared_ptr named shared not because you "can use different
>deallocators" with the same type (though in some cases it is very
>convenient), but because it model some "Idea" of sharing. The way this
>sharing is achieved is not important - it still should be shared_ptr. While
>the way how pointer/resource is destroyed is secondary in this sense. Why
>don't you name you semantic: ptr_with_custom_deleter?
>
>In some cases when we want to emphasize type of sharing in use we may name
>smart pointer as intrusive_ptr or ref_linked_ptr. But what in a name? The
>real issue for me is to understand: do we need "unified" smart_ptr, why, and
>how it should like.

You are correct about why we called it shared_ptr.