RE: [boost] Re: Cyclic smart pointers (holy grail: the uber-point er)

From: Schoenborn, Oliver (Oliver.Schoenborn_at_[hidden])
Date: 2003-05-29 22:17:19

> -----Original Message-----
> From: Chuck Messenger [mailto:chuckm_at_[hidden]]
> Sent: Thursday, May 29, 2003 4:47 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Cyclic smart pointers (holy grail: the
> uber-pointer)
> 
> 
> Schoenborn, Oliver wrote:
> 
> >>>- 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. 
> 
> No.  A and B are completely symmetrical.  They each equally 
> "own" the other.

Not possible. This has nothing to do with NoPtr or boost::shared_ptr, it's
even true for raw pointers. E.g.

// forget about forward declarations for brevity

struct A {
    B* b;
    ~A() {delete b;} // A owns b
};
struct B {
    A* a;
    ~B() {delete a;} // B owns a
};

A* a = new A;
a->b = new B;
a->b->a = a;

delete a;    // *** illegal #1
delete a->b; // *** illegal #2

In illegal#1, a is owned by b means that only b is allowed to delete a, so
calling "delete a" ourselves is illegal (and will lead to double deletion).
In illegal#2, it's b that's being deleted, and same holds as illegal #1. So,
who destroys a and b? No one can and you have a memory leak. 

If on the other hand you have 

struct A {
    B* b;
    ~A() {delete b;} // A owns b
};
struct B {
    A* a; // B does NOT own a
};
 
then delete a is ok, but delete a->b is still not since a->b is owned by a. 

> I looked at NoPtr, and quickly determined that it didn't implement 
> garbage collection, so it couldn't solve my problem.  

That's good, because NoPtr has nothing to do with garbage collection (though
one could perhaps use it for a form of gc).

> However, I don't understand what NoPtr *does*.

Simplistically, 
- DynObj destroys what it owns when it goes out of scope, is reset or
acquires something new, and notifies any RRefs linked to it
- RRef refers to a DynObj, but asserts that DynObj still exists when
accessed

Note that I said simplistically.

Oliver