RE: [boost] Cyclic smart pointers (holy grail: the uber-pointer)

From: Schoenborn, Oliver (Oliver.Schoenborn_at_[hidden])
Date: 2003-05-29 12:09:01

> -----Original Message-----
> From: Chuck Messenger [mailto:chuckm_at_[hidden]]
> Sent: Thursday, May 29, 2003 8:26 AM
> To: boost_at_[hidden]
> Subject: [boost] Cyclic smart pointers (holy grail: the uber-pointer)
> 
> 
> Schoenborn, Oliver wrote:
> 
> > The above code does not make sense from a strict ownership 
> point of view.
> 
> In other words, traditional smart pointers, such as NoPtr, are not 
> suitable  when you need to support circular links.

No that's right, because circular links involve strict ownership only in
half the cycle. If A contains B which refers to the A containing it, clearly
B cannot be owning the A since the A contains the B. Strict ownership does
not make sense here. Therefore,

1) Given that ownership issues seem flaky with circular links, are circular
links really a good design? I would say not. 
2) If that design is really the one you have to use, then strict ownership
ALONE is of no help to you, you need reference in addition (like weak_ptr
for shared_ptr or RRef for DynObj).  
 
> > - You always have A owns A_impl owns B owns B_impl refs A (what your
> > original code seems to say), in this case B_impl contains an RRef<A> 
> > instead of a DynObj<A> and everything works

I'd like to hear whether that's your case or not. 

> Imagine that I'm supplying a network simulation library.  I have:
> 
> ...(network node code deleted for brevity)...
> 
> The the problem space is essentially circular.  There's nothing to be 
> done about it at a design level, in order to make reference 
> counting work.

I don't understand why you keep bringing in reference counting, since NoPtr
does not use it when it comes to ownership, therefore you're talking about a
problem that does not exist for NoPtr. The application domain is irrelevant:
if your problem is with ref counting and NoPtr does not use ref counting,
then you don't have that problem.

Oliver