On 02/02/2004 08:51 PM, David Abrahams wrote:
Larry Evans <cppljevans@cox-internet.com> 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
On 02/02/2004 09:23 PM, Larry Evans wrote: 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?