std::weak_ptr

Contents[Show]

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 highly limited 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 (line 13 and 14). That means in particular that std::weak doesn't incremente 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.

weakPtr

That was almost the whole story to the std::weak_ptr. Almost, because the std::weak_ptr has a special 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 exactly 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 line 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 (line 10 - 12), Son (line 25 - 27), and Daughter (line 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 holds 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 containers of the Standard Template Library (STL) 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 a lot in common with a std::vector<char>. So, there are a lot of reasons for me, to have in the next post a closer look at the memory management of both containers.

 

 

 

 


 

 

 

 

 

 

title page smalltitle page small Go to Leanpub/cpplibrary "What every professional C++ programmer should know about the C++ standard library".   Get your e-book. Support my blog.

 

Add comment


My Newest E-Book

Latest comments

Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code

Visitors

Today 728

All 332852

Currently are 227 guests and no members online