![\"gold](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/12\/gold-513062_640.png\")
<\/p>\nThere were a lot of C++ experts who said that smart pointers were the essential feature of C++11. Today, I will write about smart pointers in C++.<\/p>\n
<\/p>\n
The C++ core guidelines have thirteen rules for smart pointers. Half of them deal with their owner semantics; half of them with the question: How should you pass a shared pointer to a function?<\/p>\n
<\/p>\n
Here is an overview of the rules.<\/p>\n
unique_ptr<\/code> or shared_ptr<\/code> to represent ownership<\/a><\/li>\n- R.21: Prefer
unique_ptr<\/code> over shared_ptr<\/code> unless you need to share ownership<\/a><\/li>\n- R.22: Use
make_shared()<\/code> to make shared_ptr<\/code>s<\/a><\/li>\n- R.23: Use
make_unique()<\/code> to make unique_ptr<\/code>s<\/a><\/li>\n- R.24: Use
std::weak_ptr<\/code> to break cycles of shared_ptr<\/code>s<\/a><\/li>\n- R.30: Take smart pointers as parameters only to explicitly express lifetime semantics<\/a><\/li>\n
- R.31: If you have non-
std<\/code> smart pointers, follow the basic pattern from std<\/code><\/a><\/li>\n- R.32: Take a
unique_ptr<widget><\/code> parameter to express that a function assumes ownership of a widget<\/code><\/a><\/li>\n- R.33: Take a
unique_ptr<widget>&<\/code> parameter to express that a function reseats the widget<\/code><\/a><\/li>\n- R.34: Take a
shared_ptr<widget><\/code> parameter to express that a function is part owner<\/a><\/li>\n- R.35: Take a
shared_ptr<widget>&<\/code> parameter to express that a function might reseat the shared pointer<\/a><\/li>\n- R.36: Take a
const shared_ptr<widget>&<\/code> parameter to express that it might retain a reference count to the object ???<\/a><\/li>\n- R.37: Do not pass a pointer or reference obtained from an aliased smart pointer<\/a><\/li>\n<\/ul>\n
The first five rules (R.20 – R.24<\/strong>) are quite obvious. I have written a few posts about them. Let me paraphrase the rules and refer to my previous posts.<\/p>\nA std::unique_ptr<\/a> <\/span>is an exclusive owner of its resource; therefore, you can not copy it but only move it. In contrast, a std::shared_pointer <\/a><\/span>shares ownership. If you copy or copy assign a shared pointer, the reference counter will automatically be increased; if you delete or reset a shared pointer, the reference counter will be decreased. If the reference counter becomes zero, the underlying resource will be deleted. Because of this management overhead, you should use a std::unique_ptr<\/span>, if possible (R.21<\/strong>).<\/p>\nThis overhead becomes, in particular true if you create a std::shared_ptr<\/span>. Creating a std::shared_ptr<\/span> requires the allocation of the resource and the reference counter, which is, in sum, quite an expensive job; therefore, you should use the factory function std::make_shared <\/span>(R.22<\/strong>). std::make_shared<\/span> makes only one allocation. This is a big performance improvement for std::shared_ptr<\/span>. In comparison, in the post “Memory and Performance Overhead of Shared Pointers<\/a>” the differences between creating and deleting raw pointers and shared pointers including the factory functions std::make_shared<\/span> and std::make_unique<\/span>.<\/p>\nThere is an additional, vital reason to create an std::shared_ptr<\/span> with std::make_shared<\/span>, and an std::unique_ptr<\/span> with std::make_unique<\/span>: no memory leak (R.22 and R.23<\/strong>). Using two invocations of std::shared_ptr<\/span> or std::unique_ptr<\/span> in one expression can cause a memory leak if an exception happens. I was hoping you could read the details about this issue in my last post: C++ Core Guidelines: Rules for Allocating and Deallocating <\/a>(R.13).
<\/span><\/p>\nA std::weak_ptr i<\/span>s not a smart pointer. A std::weak_ptr<\/span> is no owner and lends only the resource from its std::shared_ptr.<\/span> Its interface is quite limited. Using the method lock on a std::weak_ptr<\/span>, you can lift a std::weak_ptr<\/span> to a std::shared_ptr<\/span>. Of course, you have a question: Why do we need a std::weak_ptr?<\/span> A std::weak_ptr<\/span> helps to break the cycles of std::shared_ptr <\/span>(R.24)<\/strong>. These cycles are the reason a std::shared_ptr<\/span> will not automatically release its resource. Or to say it the other way around. If you have a cycle of shared pointers, you will have a memory leak. Read the details of std::weak_ptr<\/span> and how you can use them to overcome memory leaks with std::shared_ptr<\/span> in my previous post std::weak_ptr.<\/span><\/a><\/p>\nNow I’m done with my summary of smart pointers. That is more or less general knowledge of smart pointers. This will not hold for the remaining rules. They deal with the question: How should you pass a shared pointer to a function?<\/p>\n<\/p>\n
R.30: Take smart pointers as parameters only to explicitly express lifetime semantics<\/a><\/h3>\nThis rule is a little bit tricky. If you pass a smart pointer as a parameter to a function and you use this function only as the underlying resource of the smart pointer, you do something wrong. In this case, you should use a pointer or a reference as a function parameter because you don’t have the lifetime semantics of a smart pointer.<\/p>\n
Let me give you an example of a smart pointer’s quite sophisticated lifetime management.<\/p>\n
<\/p>\n
<\/p>\n
\n\/\/ lifetimeSemantic.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <memory><\/span>\r\n\r\nvoid<\/span> asSmartPointerGood<\/span>(std::<\/span>shared_ptr<<\/span>int<\/span>>&<\/span> shr){\r\n std::<\/span>cout <<<\/span> \"shr.use_count(): \"<\/span> <<<\/span> shr.use_count() <<<\/span> std::<\/span>endl; \/\/ (3)<\/span>\r\n shr.reset(new<\/span> int<\/span>(2011<\/span>)); \/\/ (5)<\/span>\r\n std::<\/span>cout <<<\/span> \"shr.use_count(): \"<\/span> <<<\/span> shr.use_count() <<<\/span> std::<\/span>endl; \/\/ (4)<\/span>\r\n}\r\n\r\nvoid<\/span> asSmartPointerBad<\/span>(std::<\/span>shared_ptr<<\/span>int<\/span>>&<\/span> shr){\r\n \/\/ doSomethingWith(*shr);<\/span>\r\n *<\/span>shr +=<\/span> 19<\/span>;\r\n}\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n auto<\/span> firSha =<\/span> std::<\/span>make_shared<<\/span>int<\/span>><\/span>(1998<\/span>);\r\n auto<\/span> secSha =<\/span> firSha;\r\n std::<\/span>cout <<<\/span> \"firSha.use_count(): \"<\/span> <<<\/span> firSha.use_count() <<<\/span> std::<\/span>endl; \/\/ (1)<\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n asSmartPointerGood(firSha); \/\/ (2)<\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>cout <<<\/span> \"*firSha: \"<\/span> <<<\/span> *<\/span>firSha <<<\/span> std::<\/span>endl;\r\n std::<\/span>cout <<<\/span> \"firSha.use_count(): \"<\/span> <<<\/span> firSha.use_count() <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>cout <<<\/span> \"*secSha: \"<\/span> <<<\/span> *<\/span>secSha <<<\/span> std::<\/span>endl;\r\n std::<\/span>cout <<<\/span> \"secSha.use_count(): \"<\/span> <<<\/span> secSha.use_count() <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n asSmartPointerBad(secSha); \/\/ (6)<\/span>\r\n std::<\/span>cout <<<\/span> \"*secSha: \"<\/span> <<<\/span> *<\/span>secSha <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
I will start with the excellent case for a std::shared_ptr.<\/span> The reference counter in line (1) is two because I used the shared pointer firSha<\/span> to copy-initialized secSha. <\/span>Let’s look closer at the invocation of the function asSmartPointerGood<\/span> (2). First (3), the reference count of shr<\/span> is 2 and then becomes 1 in line (4). What happened in line (5)? I reset shr<\/span> to the new resource: new int(2011).<\/span> Consequentially, the shared pointer firSha<\/span> and secSha<\/span> are immediately shared owners of different resources. You can observe the behavior in the screenshot.<\/p>\n![\"lifetimeSemantic\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/12\/lifetimeSemantic.png\")
<\/p>\n
If you invoke reset<\/span> on a shared pointer, magic happens under the hood.<\/p>\n\n- If you invoke reset<\/span> without an argument, the reference counter will be decreased by one.<\/li>\n
- If you invoke reset<\/span> with an argument and the reference counter was at least 2, you will get two independent shared pointer owning different resources. This is a kind of deep copy<\/a> of shared pointers.<\/li>\n
- The resource will be released if you invoke reset with or without an argument and the reference counter becomes 0.<\/li>\n<\/ul>\n
This magic is not necessary if you are only interested in the underlying resource of the shared pointer; therefore, a pointer or a reference is the right parameter for the function asSmartPointerBad<\/span> (6).<\/p>\nFurther information<\/h2>\n
Look also at a recent post by Bartek F. about a situation where weak_ptr prevents full memory cleanup: How a weak_ptr might prevent full memory cleanup of a managed object<\/a>.<\/p>\nWhat’s next?<\/h2>\n