![\"photo](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/12\/photo-montage-1548599_640.png\")
<\/p>\nThis and the following posts will probably be about the most critical concern in programming: resource management. The C++ Core Guidelines have rules for resource management in general but also rules for allocation and deallocation and smart pointers in particular. Today I will begin with the general rules of resource management.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
At first. What is a resource? A resource is something that you have to manage. That means you must acquire and release it because resources are limited, or you must protect them. You can only have a limited amount of memory, sockets, processes, or threads; only one process can write a shared file, or one thread can write a shared variable at one point. If you don’t follow the protocol, many issues are possible.<\/p>\n
Your system may<\/p>\n
The issues with data race and data locks are not unique to shared variables. For example, you can have the same issues with files.<\/p>\n
If you think about resource management, it all boils down to one key point: ownership. So let me give you first the big picture before I write about the rules.<\/p>\n
What I like in particular about modern C++ is that we can directly express our intention about ownership in code.<\/p>\n
Compare this fine-grained ownership semantic to just a raw pointer. Now you know, what I like about modern C++.<\/p>\n
Here is a summary of the rules for resource management.<\/p>\n
T*<\/code>) is non-owning<\/a><\/li>\n- R.4: A raw reference (a
T&<\/code>) is non-owning<\/a><\/li>\n- R.5: Prefer scoped objects, don\u2019t heap-allocate unnecessarily<\/a><\/li>\n
- R.6: Avoid non-
const<\/code> global variables<\/a><\/li>\n<\/ul>\nLet’s look at each of them in detail.<\/p>\n
R.1: Manage resources automatically using resource handles and RAII (Resource Acquisition Is Initialization)<\/a><\/h3>\nThe idea is quite simple. You create a kind of proxy object for your resource. The proxy’s constructor will acquire the resource, and the destructor will release the resource. The key idea of RAII is that the C++ runtime is the owner of the local object<\/strong> and, therefore, of the resource.<\/p>\nTwo typical examples of RAII in modern C++ are smart pointers and locks. Smart pointer takes care of their memory, and locks care for their mutexes.<\/p>\n
The following class ResourceGuard<\/span> models RAII.<\/p>\n<\/p>\n
\n\/\/ raii.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <new><\/span>\r\n#include <string><\/span>\r\n\r\nclass<\/span> ResourceGuard<\/span>{\r\n private:<\/span>\r\n const<\/span> std::<\/span>string resource;\r\n public:<\/span>\r\n ResourceGuard(const<\/span> std::<\/span>string&<\/span> res):<\/span>resource(res){\r\n std::<\/span>cout <<<\/span> \"Acquire the \"<\/span> <<<\/span> resource <<<\/span> \".\"<\/span> <<<\/span> std::<\/span>endl;\r\n }\r\n ~<\/span>ResourceGuard(){\r\n std::<\/span>cout <<<\/span> \"Release the \"<\/span><<<\/span> resource <<<\/span> \".\"<\/span> <<<\/span> std::<\/span>endl;\r\n }\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n\r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n ResourceGuard resGuard1{\"memoryBlock1\"<\/span>}; \/\/ (1)<\/span>\r\n\r\n std::<\/span>cout <<<\/span> \"<\/span>\\n<\/span>Before local scope\"<\/span> <<<\/span> std::<\/span>endl;\r\n {\r\n ResourceGuard resGuard2{\"memoryBlock2\"<\/span>}; \/\/ (2)<\/span>\r\n }\r\n std::<\/span>cout <<<\/span> \"After local scope\"<\/span> <<<\/span> std::<\/span>endl;\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n\r\n \r\n std::<\/span>cout <<<\/span> \"<\/span>\\n<\/span>Before try-catch block\"<\/span> <<<\/span> std::<\/span>endl;\r\n try{\r\n ResourceGuard resGuard3{\"memoryBlock3\"<\/span>}; \/\/ (3)<\/span>\r\n throw<\/span> std::<\/span>bad_alloc();\r\n } \r\n catch<\/span> (std::<\/span>bad_alloc&<\/span> e){\r\n std::<\/span>cout <<<\/span> e.what();\r\n }\r\n std::<\/span>cout <<<\/span> \"<\/span>\\n<\/span>After try-catch block\"<\/span> <<<\/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
It makes no difference if the lifetime of instances of ResourceGuard<\/span> ends regularly (1) and (2) or irregularly (3). The destructor of ResourceGuard<\/span> will always be called. This means the resource will be released.<\/p>\n![\"raii\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2016\/12\/raii.png\")
<\/p>\n
Read my post: Garbage Collection – No Thanks for more details about the example and RAII. Even Bjarne Stroustrup made a comment.<\/p>\n<\/p>\n
R.2: In interfaces, use raw pointers to denote individual objects (only)<\/a><\/h3>\nRaw pointers should not denote arrays because this is very error-prone. This becomes, in particular, true if your function takes a pointer as an argument.<\/p>\n
<\/p>\n
\nvoid<\/span> f<\/span>(int<\/span>*<\/span> p, int<\/span> n) \/\/ n is the number of elements in p[]<\/span>\r\n{\r\n \/\/ ...<\/span>\r\n p[2<\/span>] =<\/span> 7<\/span>; \/\/ bad: subscript raw pointer<\/span>\r\n \/\/ ...<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
It’s quite easy to pass the wrong side of the array as an argument.<\/p>\n
For arrays, we have containers such as std::vector<\/span>. A container of the Standard Template Library is an exclusive owner. It acquires and releases its memory automatically.<\/p>\nR.3: A raw pointer (a T*<\/code>) is non-owning<\/a><\/h3>\nThe issue of ownership becomes in particular interesting if you have a factory. A factory is a special function that returns a new object. Now the question is. Should you return a raw pointer, an object, a std::unique_ptr,<\/span> or a std::shared_ptr<\/span>?<\/p>\nHere are the four variations:<\/p>\n
<\/p>\n
\nWidget*<\/span> makeWidget<\/span>(int<\/span> n){ \/\/ (1)\r\n auto<\/span> p =<\/span> new<\/span> Widget{n};\r\n \/\/ ...<\/span>\r\n return<\/span> p;\r\n}\r\n\r\nWidget makeWidget<\/span>(int<\/span> n){ \/\/ (2)\r\n Widget g{n};\r\n \/\/ ...<\/span>\r\n return<\/span> g;\r\n}\r\n\r\nstd::<\/span>unique_ptr<<\/span>Widget><\/span> makeWidget(int<\/span> n){ \/\/ (3)\r\n auto<\/span> u =<\/span> std::<\/span>make_unique<<\/span>Widget>(n);\r\n \/\/ ...<\/span>\r\n return<\/span> u;\r\n}\r\n\r\nstd::<\/span>shared_ptr<<\/span>Widget><\/span> makeWidget(int<\/span> n){ \/\/ (4)\r\n auto<\/span> s =<\/span> std::<\/span>make_shared<<\/span>Widget>(n);\r\n \/\/ ...<\/span>\r\n return<\/span> s;\r\n}\r\n\r\n...\r\n\r\nauto<\/span> widget =<\/span> makeWidget(10<\/span>);\r\n<\/pre>\n<\/div>\n <\/p>\n
Who should be the owner of the widget? The caller or the callee? I assume you can not answer the question for the pointer in the example. Me too. This means we have no idea who should call delete.
In contrast, cases (2) to (4) are apparent. In the case of the object or the std::unique_ptr<\/span>, the caller is the owner. In the case of the std::shared_ptr<\/span>, the caller and the callee share the ownership.<\/p>\nOne question remains. Should you go with an object or a smart pointer? Here are my thoughts.<\/p>\n
\n- If your factory is polymorphic, such as a virtual constructor, you must use a smart pointer. I have already written about this special use case. Read the details in the post: C++ Core Guidelines: Constructors<\/a> (C.50).<\/li>\n
- If the object is cheap to copy and the caller should be the owner of the widget, use an object. If not cheap to copy, use a std::unique_ptr.<\/span><\/li>\n
- If the callee wants to manage the lifetime of the widget, use a std::shared_ptr<\/span><\/li>\n<\/ul>\n
R.4: A raw reference (a T&<\/code>) is non-owning<\/a><\/h3>\nThere is nothing to add. A raw reference is non-owning and cannot be empty.<\/p>\n
R.5: Prefer scoped objects, don\u2019t heap-allocate unnecessarily<\/a><\/h3>\nA scoped object is an object with its scope. That may be a local object, a global object, or a member. The C++ runtime takes care of the object. No memory allocation and deallocation are involved, and we can not get a std::bad_alloc<\/span> exception. To make it simple: If possible, use a scoped object.<\/p>\nR.6: Avoid non-const<\/code> global variables<\/a><\/h3>\nI often hear: global variables are bad. That is not true. Non-const global variables are bad. There are many reasons for avoiding non-const global variables. Here are a few reasons. I assume, for simplicity reasons, that the functions or objects use non-const global variables.<\/p>\n
\n- Encapsulation<\/strong>: Functions or objects could be changed outside of their scope. This means it is pretty challenging to think about your code.<\/li>\n
- Testability:<\/strong> You can not test your function in isolation. The effect of your function depends on the state of your program.<\/li>\n
- Refactoring:<\/strong> Refactoring your code is pretty challenging if you can not think about your function in isolation.<\/li>\n
- Optimization:<\/strong> You can not easily rearrange the function invocations or perform the function invocations on different threads because there may be hidden dependencies.<\/li>\n
- Concurrency:<\/strong> The necessary condition for having a data race<\/a> is a shared, mutable state. Non-const global variables are shared mutable states.<\/li>\n<\/ul>\n
What’s next?<\/h2>\n