Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk