Question

When an object b internally refers to and uses an object a it does not own, the death of a can make b sick. Here is a minimal example to illustrate the point:

#include <iostream>

const int my_int = 5;

class A {
  private:
    int n_;
  public:
    int n() const { return n_; }
    A(int);
};

A::A(int n__) : n_(n__) {}

class B {
  private:
    const A *ap_;
  public:
    int m() const { return 1 + ap_->n(); }
    explicit B(const A *);
};

B::B(const A *const ap__) : ap_(ap__) {}

int main()
{
    std::cout << "Will put an unnamed A on the heap.\n";
    A *const p = new A(my_int);
    std::cout << "Have put an unnamed A on the heap.\n";
    std::cout << "p->n() == " << p->n() << "\n";
    B b(p);
    std::cout << "b. m() == " << b. m() << "\n";
    std::cout << "Will delete  the unnamed A from the heap.\n";
    delete p;
    std::cout << "Have deleted the unnamed A from the heap.\n";
    std::cout << "b. m() == " << b. m() << "\n"; // error
    return 0;
}

Of course, one could fix this by letting b keep a copy of a rather than a pointer to it, but suppose that b prefers not to keep a copy (because a occupies a lot of memory or for some other reason). Suppose that b prefers merely to refer to the existing a. When a quietly dies, b never notices. Then, when b tries to use a, unpredictable behavior results.

On my computer, the example’s output happens to be this:

Will put an unnamed A on the heap.
Have put an unnamed A on the heap.
p->n() == 5
b. m() == 6
Will delete  the unnamed A from the heap.
Have deleted the unnamed A from the heap.
b. m() == 1

However, on your computer, the result might be a segfault or who knows what.

My example’s trouble seems to lie in that the example indirectly breaks the encapsulation of b, leaving it to the programmer to remember that the continued validity of b depends on the continued existence of a. When the programmer forgets, the program breaks. The harassed programmer thus is required to keep b in mind whenever he works on a even though the type A as such does not care about the type B. As you know, object-oriented programmers prefer not to have to keep such trivia in mind if they can help it.

I meet this problem under more complicated guise now and then while programming. I have met it again today. One feels that, somehow, there should exist an elegant design pattern to maintain the proper encapsulation of b, to transfer from the programmer to the compiler the responsibility of remembering b‘s dependence on a‘s existence — and that the pattern fundamentally should involve something less elaborate than smart pointers and full-blown reference counting. However, maybe I am wrong. Maybe this is exactly what smart pointers their reference counting are for. Either way, I know neither the right pattern to apply against the problem nor the best way to fix the code.

If you do know, would you tell about it?

Here is the most nearly related answer I notice already on Stackoverflow; but, besides using one or two words I do not understand, that answer does not seem to answer this question, anyway.

(My compiler still does not happen to support C++11 very well, but if C++11 brings a feature specifically meant to address my problem, then of course I should be interested to learn of it. Admittedly however, my question mainly concerns OO/scoping fundamentals. The question is even more interested in the underlying design pattern than in this or that new feature of the latest compiler.)

NOTE TO THE READER

Some good answers have graced this question. On Stackoverflow, as you know, the asker has the responsibility to accept the best answer so that (when you read this months or years later) you will not have to search for it.

However, it is the combination of two answers that best answers this question. You should read both:

• @MatthieuM.’s answer re shared ownership and the observer pattern; and
• @JamesKanze’s answer re why and when the observer pattern may be preferred.

Answer 1

I can think of two particular solutions:

• shared ownership
• observer pattern

In the shared ownership solution, the lifetime of a is determined by a counter of the number of owners, only when there is no owner any longer does a‘s lifetime come to an end. This is typically implemented using std::shared_ptr<A>.

In the observer solution, when a is passed to b, a memorizes that b holds a reference to it. Then, when a dies, either it notifies b right away or leave a “token” behind for b to be notified at the next access attempt.

The direct notification is usually handled by maintaining a list of the current referrers and calling to each of them at destruction time (so they can erase their reference). It is the typical observer pattern.

The indirect notification is usually handled by having a proxy object to go through to get to a. When a dies the proxy is notified (O(1)) and when b attempts to access a it must pass through the proxy. There are various difficulties in implementing this on your own, a better approach is therefore to use standard facilities: std::shared_ptr this time combined with std::weak_ptr.

Finally, these solutions are not equivalent.

• shared ownership implies that a cannot die whilst b lives while an observer scheme allows a to die first
• direct notification lets b react immediately about a‘s death, but at the same time may make the program more brittle (during a‘s destructor execution, you should not throw any exception)

Choose your own poison 🙂