Re: [boost] Re: cyclic ptr (was: Re: Re: Re: Re: Re: Re: Re: Proposals: p2m offsets, prebuild<>, squad_ptr<> (of course))

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2002-09-07 12:48:43

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?"

>conservative collector can fail to release memory.  And besides, if you
>are going with a conservative collector there is no need for any smart
>pointers.
>  
>
I was unclear. I wasn't going to use the cmm code to do conservative 
collection.
I was going go use it to diagnose invalid uses of shared_cyclic_ptr. For 
example,
if the smart_ptr's are used correctly (for example, 
vector<shared_cyclic_ptr<subj> >
instead of scoped_cyclic_container<vector,subj,...>) then neither 
ip_assign_op_swith or
ip_offset_iterator would work. In the first case, because the vector 
would not assign each
element if phase indicated gc was being done, and in the second case, 
because no offset
to the containing vector was calculated.