Boost logo

Boost :

Subject: Re: [boost] [Root Pointer] Seeking a Review Manager
From: Rob Stewart (rstewart_at_[hidden])
Date: 2016-04-04 04:27:13


On April 3, 2016 8:53:34 PM EDT, Phil Bouchard <philippeb8_at_[hidden]> wrote:
>On 04/03/2016 08:32 PM, Edward Diener wrote:
>>
>> I still am not getting what root_ptr<someType> is. Is it a
>> replacement for shared_ptr ?
>
>There is no performance loss in using root_ptr/node_ptr over shared_ptr
>so therefore yes it is a replacement for shared_ptr/weak_ptr.

That isn't quite an answer to his question. If I understand you correctly, the point of your library is to provide a means to manage groups of related memory allocations using a root_pointer. Each related memory allocation is, I presume, a node_pointer created from, or attached to, one root_pointer. Because node_ptrs are grouped and owned by a root_ptr, they are (can be?) destroyed, as a group, when the corresponding root_ptr is destroyed, regardless of cycles.

That doing so suffers no performance loss relative to shared_ptr is a bonus, not a reason.

>> What is node_ptr<someType> ? How does a root_ptr relate
>> to a node_ptr ?
>
>root_ptr has a 1 to many relationship with node_ptr which means only 1
>root_ptr should be used to refer to multiple node_ptrs. Just like:
>- a container (1 root with multiple nodes) or
>- the implementation of a webpage in C++ (1 root per page with mutliple
>HTML elements)

Did I get the relationship correct above?

>> Can there be numerous root_ptrs and node_ptrs for any
>> given 'someType' ?
>
>Yes a class can have multiple roots to some instantiations of the class
>and each instantiation can have numerous number of node_ptrs contained
>within.

Knowing the purpose of each, add I described them above, would have answered that question.

>> What root_ptr and node_ptr syntax solves cyclic
>> dependencies and how does this work ?
>
>I'll document that.

I answered that on one paragraph above, didn't I?

HTH

___
Rob

(Sent from my portable computation engine)


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