weakPtr

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// 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.

 

Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.

     

    weakPtr

    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.

    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.

    cycle

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

     

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    // 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.

    cycle

    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.

     

     

     

     

     

    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, Kris Kafka, 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, Dmitry Farberov, 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, moon, Philipp Lenk, Hobsbawm, and Charles-Jianye Chen.

    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

    Seminars

    I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

    Standard Seminars (English/German)

    Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

    • C++ – The Core Language
    • C++ – The Standard Library
    • C++ – Compact
    • C++11 and C++14
    • Concurrency with Modern C++
    • Design Pattern and Architectural Pattern with C++
    • Embedded Programming with Modern C++
    • Generic Programming (Templates) with C++
    • Clean Code with Modern C++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,

     

     

    0 replies

    Leave a Reply

    Want to join the discussion?
    Feel free to contribute!

    Leave a Reply

    Your email address will not be published. Required fields are marked *