From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-09-07 13:45:51
At 11:48 AM 9/7/2002, Larry Evans wrote:
>Greg Colvin wrote:
>
>>At 10:39 AM 9/7/2002, Larry Evans wrote:
>>
>>
>>>Larry Evans wrote:
>>>
>>>
>>>
>>>>Greg Colvin wrote:
>>>>
>>>>Anyway, the shared_ptr and shared_count also were modified to allow this. I could
>>>>post these if you want, or I could give further explanation. I realize this is kinda sketchy,
>>>>but let me know and I try and be clearer.
>>>>
>>>Another modification I was thinking of was using the allocator from the conservative
>>>collector of cmm (ftp://ftp.di.unipi.it/pub/project/posso/cmm/cmm.tgz). I figured
>>>it could be used to enumerate all the allocated objects (much like iterating
>>>through cyclic_ptr's recycler's handles). In addition, since this is a conservative collector,
>>>it would be easy to check for any leaks. What do you think? Also, it could be used
>>>to eliminate the need for a weak_ptr count (as mentioned in my earlier post about "conserve+
>>>shared_ptr advantages.")
>>>
>>
>>Sounds like a tradoff -- the advantages of a custom allocator versus the
>>convenience to the user of using whatever allocator they want. Also, a
>Good point. In other words, using recycler::handles (I think that's the right name)
>is the custom allocator, and your point is that that would be faster than using
>the cmm allocator. Right? But I was thinking that the allocator, whether
>the c standard malloc or cmm, is going to do the work anyway (cmm would have
>to do a little more), why not use it. The question is, how much is "a little more?"
As I recall, my cyclic_ptr hacked up its own handle allocator, but let
the user allocate shared objects with ordinary operator new. I think
the cmm allocator would have to replace operator new to do its job. If
we are going to integrate cyclic_ptr into the latest shared_ptr/weak_ptr/
intrusive_ptr framework then allocating shared objects should be under
the user's control, not the garbage collector's.