Weak Pointers with std::weak_ptr

In our previous lessons, we've explored the intricacies of smart pointers in C++, focusing on how they automate memory management through an ownership model.

We've seen how unique pointers (std::unique_ptr) provide a way to uniquely own and automatically clean up resources.

We've also examined shared pointers (std::shared_ptr), which allow multiple objects to share ownership of a single resource using reference counting. This approach ensures that the resource is only deallocated when all owners have been destroyed.

Finally, let's turn our attention to the last smart pointer variation: weak pointers.

Understanding Weak Pointers

Weak pointers work closely with shared pointers, with one key difference: they do not actively participate in the ownership and lifecycle management of the objects they point to.

This means they have a view of the resource but do not affect its lifespan. The life of the resource is governed solely by its shared pointer owners.

If all shared pointers to an object are destroyed, the object is deallocated, and the weak pointer becomes expired - a reference to something that no longer exists.

Weak pointers shine in several scenarios:

Breaking Circular References

Consider two objects, each holding a shared pointer to the other. They create a cycle, much like two friends promising to leave a party only when the other does.

This circular dependency prevents either of them from being deallocated. By converting one connection to a weak pointer, we break this cycle, enabling proper cleanup.

Handling Dangling Pointers

Dangling pointers are like outdated addresses - they point to a location where the intended object no longer resides. As we’ll see later in the lesson, it’s quite hard to detect when a raw pointer is dangling, but very easy when we’re using a weak pointer instead.

Caching Mechanisms

In caching, where objects are stored temporarily for quick access, weak pointers can reference these objects without affecting their lifecycle. We’ll cover caching in detail later in the course.

Creating Weak Pointers

Similar to other standard library smart pointers, weak pointers are available by including <memory>, and they have a template parameter specifying which type of object they’re pointing to.

In the following example, we create a weak pointer to point at an int:

1#include <memory>
2
3int main() {
4  std::weak_ptr<int> WeakPtr;
5}

Commonly, weak pointers are initialized from a shared pointer:

1#include <memory>
2
3int main() {
4  auto SharedPtr { std::make_shared<int>(42) };
5  std::weak_ptr<int> WeakPtr{SharedPtr};
6}

When creating a weak pointer from a shared pointer, the type within the <> can be deduced from the equivalent type of the shared pointer - int, in this case. So it is not necessary to include it:

1#include <memory>
2
3int main() {
4  auto SharedPtr { std::make_shared<int>(42) };
5  std::weak_ptr WeakPtr{SharedPtr};
6}

The arguments we pass between chevrons < and > are called template parameters. We cover templates in detail in a dedicated chapter later in the course.

use_count() and expired() Methods

Similar to shared pointers, weak pointers have the use_count() method, which returns how many pointers are sharing ownership of the object.

1#include <memory>
2#include <iostream>
3
4struct Resource {
5  ~Resource(){ std::cout << "\nDeallocating"; }
6};
7
8int main(){
9  auto SharedPtr{std::make_shared<Resource>()};
10  std::weak_ptr WeakPtr{SharedPtr};
11
12  std::cout << "Use count: " <<
13    WeakPtr.use_count(); 
14
15  SharedPtr.reset();
16
17  std::cout << "\nUse count: " <<
18    WeakPtr.use_count(); 
19}

A weak pointer is not considered an owner - as such, it does not participate in the count, and it does not keep the resource alive:

1Use count: 1
2Deallocating
3Use count: 0

When a weak pointer has a use_count() of 0, that indicates the underlying resource has been deallocated. Any weak pointers that point to it will be considered expired.

We can specifically check for this using the more descriptive expired() method:

1#include <memory>
2#include <iostream>
3
4int main(){
5  auto SharedPtr{std::make_shared<int>(42)};
6  std::weak_ptr WeakPtr{SharedPtr};
7
8  if (!WeakPtr.expired()) {
9    std::cout << "The pointer hasn't expired";
10  }
11
12  SharedPtr.reset();
13
14  if (WeakPtr.expired()) {
15    std::cout << "\nBut now it has";
16  }
17}

1The pointer hasn't expired
2But now it has

Accessing Objects through a Weak Pointer

Accessing an object through a weak pointer is a little more complex than accessing an object through other smart pointer types, such as shared pointers or unique pointers. This is to account for the fact that, unlike other smart pointers, weak pointers can potentially have expired.

To use the underlying object, we first need to create a shared pointer from our weak pointer, thereby registering an owner. This is sometimes referred to as locking the weak pointer.

This may seem like a weird restriction, but it’s a protection against issues that can arise when we’re working in multi-threaded environments.

If we don’t first lock our object, something happening on another thread might drop the use_count() to 0. This would cause the object to be deallocated whilst we’re still using it.

We create a shared pointer from our weak pointer using the lock() method:

1#include <memory>
2#include <iostream>
3
4int main(){
5  auto SharedPtr{std::make_shared<int>(42)};
6  std::weak_ptr WeakPtr{SharedPtr};
7
8  std::shared_ptr LockedPtr{WeakPtr.lock()};
9  std::cout << "The number is: " << *LockedPtr;
10}

1The number is: 42

In this basic example, we know the object will not have expired, but rarely are our use cases this simple. Typically, when we have a weak pointer, we don’t know if it has expired or not - we need to check.

We can do that using the expired() method as described earlier in the lesson.

Alternatively, if the pointer has expired, lock() will return an empty shared pointer. We can check if a pointer is empty simply by coercing it into a boolean.

As such, a common pattern for working with weak pointers that may have expired looks like this:

1#include <memory>
2#include <iostream>
3
4void Log(std::weak_ptr<int> Ptr){
5  if (std::shared_ptr LockedPtr{Ptr.lock()}) {
6    std::cout << "The number is " << *LockedPtr;
7  } else {
8    std::cout << "\nThe pointer has expired";
9  }
10}
11
12int main(){
13  auto SharedPtr{std::make_shared<int>(42)};
14  std::weak_ptr WeakPtr{SharedPtr};
15  Log(WeakPtr);
16  SharedPtr.reset();
17  Log(WeakPtr);
18}

1The number is 42
2The pointer has expired

The most common place we’ll see weak pointers is class variables. We’ll often have a class that needs to keep a reference to some other object, without necessarily keeping that object alive.

The following example replicates the same concepts in a slightly more complex context:

1#include <memory>
2#include <iostream>
3
4class Character {
5public:
6  std::string Name;
7};
8
9class Party {
10public:
11  std::weak_ptr<Character> Leader; 
12
13  std::string LeaderName(){
14    if (std::shared_ptr Lead{Leader.lock()}) {
15      return Lead->Name;
16    }
17    return "No Leader";
18  }
19};
20
21int main(){
22  auto Leader{
23    std::make_shared<Character>("Anna")
24  };
25
26  Party MyParty{Leader};
27
28  std::cout << "Party Leader: "
29    << MyParty.LeaderName();
30
31  Leader.reset();
32
33  std::cout << "\nParty Leader: "
34    << MyParty.LeaderName();
35}

1Party Leader: Anna
2Party Leader: No Leader

Weak Pointers vs Raw Pointers

At this point, a common question is to ponder whether weak pointers have any advantages over raw pointers. They have very similar properties: they both provide access to an object in memory, without claiming any ownership over it or affecting its lifecycle.

The key advantage of weak pointers is the ability to know whether what they point to has expired. This may seem trivial, but this additional layer of awareness is extremely valuable in large projects.

When we have a raw pointer to an object, and that object is later deallocated, we are left with a dangling pointer. The pointer still points to that memory address but is unaware that anything has changed, and we have no easy way to check:

1#include <iostream>
2
3int main(){
4  auto SharedPtr{std::make_shared<int>(42)};
5  int* RawPtr{SharedPtr.get()};
6  if (RawPtr) {
7    std::cout << "RawPtr is truthy | Value: "
8      << *RawPtr;
9  }
10
11  SharedPtr.reset();
12
13  if (RawPtr) {
14    std::cout << "\nStill truthy | Value: "
15      << *RawPtr;
16  }
17}

1RawPtr is truthy | Value: 42
2Still truthy | Value: -572662307

When working with raw pointers, a common pattern to prevent dangling pointers is to ensure we set them to null when we delete the underlying resource:

1#include <iostream>
2
3int main(){
4  auto SharedPtr{std::make_shared<int>(42)};
5  int* RawPtr{SharedPtr.get()};
6  if (RawPtr) {
7    std::cout << "RawPtr is truthy | Value: "
8      << *RawPtr;
9  }
10
11  SharedPtr.reset();
12  RawPtr = nullptr;
13
14  if (RawPtr) {
15    std::cout << "\nStill truthy | Value: "
16      << *RawPtr;
17  } else {
18    std::cout << "\nIt's now a nullptr";
19  }
20}

1RawPtr is truthy | Value: 42
2It's now a nullptr

But in complex programs, this is not always easy to do. Many pointers to a resource can be stored in many different objects around our application. Rather than trying to manage that manually, it’s much easier and safer to just use a weak pointer.

However, that doesn’t mean we should never use raw pointers. Raw pointers are more performant and flexible, and in short-lived code, such as a simple function call, memory management is often trivial or irrelevant.

Because of this, balancing memory management considerations against code complexity is generally something to decide on a case-by-case basis, and our instincts get better here with experience.

Next Lesson

Copy Semantics and Return Value Optimization

Learn how to control exactly how our objects get copied, and take advantage of copy elision and return value optimization (RVO)

ContinueView Course