weak_ptr and parent-child cyclic dependencies

Question

I currently have something similar to the following:

class Parent
{
    //just a single child... for sake of simplicity
    //no other class holds a shared_ptr reference to child
    shared_ptr<Child> _child; 
    System * getSystem() {...}
}

class Child
{
    weak_ptr<Parent> _parent;
    ~Child 
    { 
        _parent.lock()->getSystem()->blah(); 
    }
}

The Child destructor always crashes, since when ~Child() runs _parent is always expired. Is there a typical solution to this weirdness?

In short, is there a way to not destroy _parent until ~Child finishes?

In the long run, circular dependencies always take more effort to maintain than it would take to eliminate them in the first place. Is this possible in your case? — Shaggy Frog, Dec 18 '10 at 01:16
I don't quite understand your design. Why don't you call `getSystem()->blah()` from `Parent`'s destructor? Your design seem to have reversed the responsibilities. — Johannes Schaub - litb, Dec 18 '10 at 03:32
This is how not to use weak_something to "fix" a circular dependency problem. — curiousguy, Nov 28 '11 at 03:28

score 2 · Accepted Answer · answered Dec 18 '10 at 01:24

Since by the time the destructor for the the child gets called, the parent's destructor has already run (dtors for member objects get run after the dtor for the containing object), even if the child was holding a plain pointer to the parent, calling the parent's member function would be invalid by the time ~Child() was called.

You might be able to work around this by having Child call getSystem() at some earlier point and cache the result. Maybe in the constructor of Child (if it has a reference to the parent at the time) or maybe there can be an interface added so that Parent can let the child know it needs to collect whatever it might need during destruction from the parent at that time.

I understand that neither of these is a great solution (it increases coupling of the objects) -hopefully someone will post a better option.

score 2 · Answer 2 · answered Dec 18 '10 at 01:33

2

Removing the circular reference is preferable, but if you cannot you can force Child to be destroyed before Parent is completely gone. In the destructor, explicitly call reset() on Child. This will force it to be destroyed immediately, assuming there are no other shared_ptrs to it.

Warning, if Parent is actually a base class all of it's subclasses will alreayd have been destroyed. Virtual function calls will probably not behave as expected.

answered Dec 18 '10 at 01:33

Chris Pitman

12,990
3
41
56

I believe the member you're looking for is `clear`, not `reset` :) – Billy ONeal Dec 18 '10 at 01:39
This sounds really similar to standard memory management :) arr smart pointers... – jameszhao00 Dec 18 '10 at 01:47
@Bill ONeal: Nope, pretty sure it is reset in Boost (which I believe is the most common implementation of shared_ptr). Does the C++0x implemention have a different interface? – Chris Pitman Dec 18 '10 at 02:32
Sorry --- thought that was a `vector` of children. :P – Billy ONeal Dec 18 '10 at 05:32

score 2 · Answer 3 · answered Dec 18 '10 at 09:36

2

First rule of weak_ptr: always check the locking (returned pointer or exception): after all the real reason to use weak_ptr is that it doesn't control the life-cycle of the pointed object.

answered Dec 18 '10 at 09:36

stefaanv

14,072
2
31
53

score 2 · Answer 4 · answered Nov 28 '11 at 03:27

_parent.lock()->

Here you assume that lock will succeed, IOW that your weak_ptr will not have expired at that time.

So, you should not be using a weak_ptr at all, but a shared_ptr instead.

Things will be much more clear if you do not misuse weak_ptr. You will see that you have two objects that try to manage each other lifetime, and that your design needs to be fixed. (Throwing weak_ptr into the mix does not fix a design.)

score 0 · Answer 5 · answered Dec 18 '10 at 06:49

0

Just from the code you posted this should work. The only thing deleting _child is the parent class.

So there are two possibilites: First, something else also has a reference to the _child pointer, and keeps it ref count alive, and then parent is destroyed. Then eventually whatever else is holding onto child is also destroyed, killing off the child then.

Scenario 2 is that the call to getSystem depends on some other members youre not showing us, and those are getting deleted before the _child shared_ptr is.

answered Dec 18 '10 at 06:49

Lance Diduck

1,513
9
11

It doesn't work because the child's destruction is instigated by the parent's destruction (the child is owned by the parent). So by the time the child's destructor is called, the parent's destructor has already been called (and the parent is still in the process of destructing). – Brent Bradburn Feb 25 '11 at 05:41

weak_ptr and parent-child cyclic dependencies

5 Answers5