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.
std::weak_ptr doesn’t change – in opposite to the std::shared_ptr – the reference counter of the shared variable. Have a look.
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.
You will get cyclic references of std::shared_ptr if the std::shared_ptr reference each other.
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.
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.
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, Matthieu Bolt, 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, and Marco Parri Empoli.
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|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
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++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,