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 ( 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, gregod at, cpdaniel at, john at