std::weak_ptr

std::unique_ptr models the concept of exclusive ownership, std::shared_ptr the concept of shared ownership. If I stick to this picture then std::weak_ptr models the concept of temporary ownership because it borrows the resource from a std::shared_ptr. There is one dominant reason for having a std::weak_ptr in C++: breaking of cyclic references of std::shared_ptr‘s.

If you study the interface of the smart pointer std::weak_ptr, you will recognize: the std::weak_ptr is not so smart. std::weak_ptr has a minimal interface.

The interface

std::weak_ptr doesn’t change – in opposite to the std::shared_ptr – the reference counter of the shared variable. Have a look.

// weakPtr.cpp

#include <iostream>
#include <memory>

int main(){

  std::cout << std::boolalpha << std::endl;

  auto sharedPtr=std::make_shared<int>(2011);
  std::weak_ptr<int> weakPtr(sharedPtr);
  
  std::cout << "weakPtr.use_count(): " << weakPtr.use_count() << std::endl;
  std::cout << "sharedPtr.use_count(): " << sharedPtr.use_count() << std::endl;
  std::cout << "weakPtr.expired(): " << weakPtr.expired() << std::endl;

  if( std::shared_ptr<int> sharedPtr1 = weakPtr.lock() ) {
    std::cout << "*sharedPtr: " << *sharedPtr << std::endl;
    std::cout << "sharedPtr1.use_count(): " << sharedPtr1.use_count() << std::endl;
  }
  else{
    std::cout << "Don't get the resource!" << std::endl;
  }

  weakPtr.reset();
  if( std::shared_ptr<int> sharedPtr1 = weakPtr.lock() ) {
    std::cout << "*sharedPtr: " << *sharedPtr << std::endl;
    std::cout << "sharedPtr1.use_count(): " << sharedPtr1.use_count() << std::endl;
  }
  else{
    std::cout << "Don't get the resource!" << std::endl;
  }

  std::cout << std::endl;

}

I create in line 11 a std::weak_ptr which borrows the resource from the std::shared_ptr. The output of the program shows that the reference counter is 1 (lines 13 and 14). That means in particular that std::weak doesn’t increment the counter. The call weakPtr.expired() checks if the resource was already deleted. That is equivalent to the expression weakPtr.use_count() == 0. If the std::weak_ptr shared temporary a resource, you can use weakPtr.lock() to create a std::shared_ptr out of it. Now, the reference counter will be increased to 2 (line 18). After resetting the weakPtr (line 25), the call weakPtr.lock() fails.

That was almost the whole story of the std::weak_ptr. Almost, because the std::weak_ptr has an extraordinary job. It helps to break cyclic references of std::shared_ptr’s.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

Cyclic references

You will get cyclic references of std::shared_ptr if the std::shared_ptr reference each other.

The issue

If you have a cyclic reference of std::shared_ptr, the reference counter will never become 0. Therefore, the resource will automatically be deleted. But that is precisely the reason, why we use std::shared_ptr’s. Need an example?

There are two cycles in the graphic. First, between the mother and her daughter; second, between the mother and her son. The subtle difference is, however, that the mother references her daughter with a std::weak_ptr. Therefore, the std::shared_ptr cycle is broken.

If you don’t like pictures, here is the corresponding source code.

// cycle.cpp

#include <iostream>
#include <memory>

struct Son;
struct Daughter;

struct Mother{
  ~Mother(){
    std::cout << "Mother gone" << std::endl;
  }
  void setSon(const std::shared_ptr<Son> s ){
    mySon=s;
  }
  void setDaughter(const std::shared_ptr<Daughter> d ){
    myDaughter=d;
  }
  std::shared_ptr<const Son> mySon;
  std::weak_ptr<const Daughter> myDaughter;
};

struct Son{
  Son(std::shared_ptr<Mother> m):myMother(m){}
  ~Son(){
    std::cout << "Son gone" << std::endl;
  }
  std::shared_ptr<const Mother> myMother;
};

struct Daughter{
  Daughter(std::shared_ptr<Mother> m):myMother(m){}
  ~Daughter(){
    std::cout << "Daughter gone" << std::endl;
  }
  std::shared_ptr<const Mother> myMother;
};

int main(){
  std::cout << std::endl;
  {
    std::shared_ptr<Mother> mother= std::shared_ptr<Mother>( new Mother);
    std::shared_ptr<Son> son= std::shared_ptr<Son>( new Son(mother) );
    std::shared_ptr<Daughter> daughter= std::shared_ptr<Daughter>( new Daughter(mother) );
    mother->setSon(son);
    mother->setDaughter(daughter);
  }
  std::cout << std::endl;
}

Thanks to the artificial scope in lines 41 – 47, the lifetime of the mother, the son, and the daughter is limited. Or to say it the other way around. Mother, son, and daughter go out of scope, and therefore the destructor of the class Mother (lines 10 – 12), Son (lines 25 – 27), and Daughter (lines 33 – 35) should automatically be invoked.

Should, because only the destructor of the class Daughter is called.

The graphic or the source code shows it. We have a cyclic reference of std::shared_ptr between mother and son. Therefore, the reference counter is always greater than 0, and the destructor will not automatically be invoked. That observation is not true for mother and daughter. If daughter goes out of scope, the reference counter of the std::shared_ptr myMother (line 36) becomes 0 and the resource will automatically be deleted.

What’s next?

The Standard Template Library (STL) containers automatically manage their memory. This holds true for the associative and the sequential container. Especially powerful is the automatic memory management of the sequential container std::vector and std::string. Although the std::string is not a sequential container of the STL, it has much in common with a std::vector<char>. So, there are many reasons for me to have in the next post a closer look at the memory management of both containers.

Post Views: 6,673

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS