[boost] Re: [policy_ptr] refcycle_counted src

From: cppljevans_at_[hidden]
Date: 2003-11-05 17:10:33

On 10/30/2003 02:01 PM, David B. Held wrote:
> <cppljevans_at_[hidden]> wrote in message
[snip]
>>I beginning to think Ownerhship and Storage should be merged
>>into a general template, OwnerStoragePolicy, that can be
>>specialized based on the Ownership and Storage policies.
> 
> 
> This has been discussed before.
>
Yep. I found it using google search on ownership+storage+policy.
I'll read some of that.

>>specialization would be an intrusive pointer.
> 
> 
> Not sure what you're getting at here.  Would you elaborate?
> 
I was thinking intrusive means the count is part of the pointee; hence,
why not have the pointee derived from the count; hence, the pointee
and count would be at same memory location. Hence, if this were so
then this could be determined at compile time with MPL magic and
the appropriate mode of pointer, intrusive or otherwise, could
be selected.
> 
>>I also tried deriving a refcycle_counted from the policy_ptr
>>ref_counted and discovered it would be easier if these 2
>>policies were merged.
> 
> 
> I would have to look closely at your policy to render an opinion.
> 
I just uploaded code and compiler output to
http://groups.yahoo.com/group/boost/files/shared_cyclic_ptr/
refcycle_counted.zip. In refcycle_counted.cpp, everyplace there's a call
to owner_as_store_owner<Referent> indicates a need for the pointee to
be available to refcycle_counted gc.  It's needed because the pointer
graph needs to be traversed and this graph is encoded as offsets from
the start of the object; hence, the start of the pointee needs to be
available.  Which brings up another question.  How does ref_counted
avoid the extra pointer used by shared_ptr to get at the start of the
object in order to do correct deletion in case of multiple inheritance?