Why do we need a weak_ptr in C++11?

Question

I was reading "The C++ Standard Library" book by Nicolai M. Josuttis for understanding weak pointers. The author has mentioned 2 reasons for the need to have a weak_ptr and I don't get the second reason. Can anyone provide a simple explanation along with example of the below reason (quoted from the book):

Another example occurs when you explicitly want to share but not own an object. Thus, you have the semantics that the lifetime of a reference to an object outlives the object it refers to. Here, shared_ptrs would never release the object, and ordinary pointers might not notice that the object they refer to is not valid anymore, which introduces the risk of accessing released data.

Answer 1

The second half of that statement should be clear: if a pointer is not an owning pointer then the object it is pointing at might be deleted by whatever software is the owner - and then you'd have the standard dangling reference.

So this issue is: you've got objects owned by some piece of software which is letting other software have access to it - but the other software won't share the ownership. So the owner can delete it at any time and the other software needs to know its pointer is no longer valid.

Maybe an example would help:

You've got some piece of software watching a camera pointing out your window to a bird feeder and it is identifying birds at the feeder, which come and go. Each bird at the feeder has an object created by this software when it arrives at the feeder, and the object is deleted when the bird flies away.

Meanwhile, some other software it taking a census. Every 10 seconds it grabs from the feeder-watching software a collection of the birds at the feeder. Every 100 seconds it emits a report of which birds were at the feeder for the entire 100 seconds.

Because the data for a bird is big the census-taker doesn't copy the data. It merely gets, every 10 seconds, a collection of pointers from the feeder-watcher.

To make it necessary to use weak pointers, let's say the feeder-watcher only provides pointers to birds which have arrived in the last ten seconds, not the ones which have been there. That is, there is no notification that birds have disappeared.

By using weak pointers it can know, at report time, which of the birds are still there, and when they arrived (but not when they left).

(Maybe I'll think of a better example later.)

Answer 2

e.g.:

struct node
{
   std::shared_ptr<node> left_child;
   std::shared_ptr<node> right_child;
   std::weak_ptr<node> parent;
   foo data;   
};

In this example, deleting the node will erase the left_child and right_child, but not the parent. If for some reason the node sticks around longer than the parent, and the parent is deleted, you have a way of knowing that the parent is no longer valid. (assuming you don't reference left_child or right_child with another shared_ptr)

Answer 3

imagine a callback function to an imaginary timer event source

struct my_thing : std::enable_shared_from_this<my_thing>
{
  void start()
  {
    auto weak_self = std::weak_ptr<my_thing>(shared_from_this());
    _timer.set_callback([weak_self] {
      if (auto self = weak_self.lock()) {
        self->respond_to_timer();
      }
    });
  }

  void respond_to_timer()
  {
    // do something here
  }

  SomeTimer _timer;
};

In the above example, my_thing owns the timer, but the timer has been given a callback which refers to the my_thing. This would be a circular reference which would prevent my_thing from ever being deleted.

The use of the weak_self weak_ptr breaks the cyclic ownership problem.