[boost] Re: shared_pointer for C-allocated object?

From: Larry Evans (cppljevans_at_[hidden])
Date: 2004-02-03 07:35:05

On 02/02/2004 09:23 PM, Larry Evans wrote:
> On 02/02/2004 08:51 PM, David Abrahams wrote:
> 
>> Larry Evans <cppljevans_at_[hidden]> writes:
>>
>>
>>> On 02/02/2004 10:32 AM, Javier Estrada wrote:
>>>
>>>> How about custom allocators AND deleters?
> 
> [snip]
> 
>>>
>>> But instead of placing two pointers(1 for allocator + 1 for deleter) why
>>> not use a virtual function table for both?  In other words, instead of
> 
> [snip]
> 
>>
>> What's the point of storing an allocator?  Once the storage for the
>> deleter is allocated, a shared_ptr never needs to allocate again.
>>
> Good point.  I can't think of a reason.  However, the idea of using
[snip]
I thought I came up with a reason:  The auto_new mentioned in the
previous post allocates a new Referent along with the Overhead
to save the extra allocation of shared_ptr for the reference counts.
This was an alternative implementation of Brouchard's idea about
saving the extra allocation with shifted_ptr:

http://article.gmane.org/gmane.comp.lib.boost.devel/31643/match=shifted+ptr

I was hoping that the vtable could contain a virtual CTOR; however,
since virtuals cannot be templated, this is not possible.  Consequently,
at least one advantage of shared_ptr cannot be achieved with auto_new.
That advantage, mentioned "eons" ago, was, IIRC, that the referent
might be allocated from thread local storage, or some special allocator
that had to have a corresponding deallocator which of course, restored
the memory to the same thread local storage.

Any ideas for solutions to this problem, i.e. how to save the extra
allocation and function pointer; yet, still solve the need for
matching allocate/delete methods?