![\"German](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/12\/German_Monopoly_board_in_the_middle_of_a_game.png\")
<\/p>\nThe guidelines have six rules for explicit memory allocation and deallocation. Six! Maybe you are surprised because there is a simple rule in modern C++: don’t use new and delete. The story is not so simple.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Here are the six rules.<\/p>\n
malloc()<\/code> and free()<\/code><\/a><\/li>\n- R.11: Avoid calling
new<\/code> and delete<\/code> explicitly<\/a><\/li>\n- R.12: Immediately give the result of an explicit resource allocation to a manager object<\/a><\/li>\n
- R.13: Perform at most one explicit resource allocation in a single expression statement<\/a><\/li>\n
- R.14: ??? array vs. pointer parameter<\/a><\/li>\n
- R.15: Always overload matched allocation\/deallocation pairs<\/a><\/li>\n<\/ul>\n
I will not write about the last two rules. First, rule R.14 is not baked enough, and second, rule R.15 is quite special. If you want to learn more about overloading new<\/span> and delete,<\/span> you should read my posts on memory allocation and deallocation<\/a>.<\/p>\nBefore I dive into the rules, let me give you a little background necessary for understanding the rules. Creating an object in C++ with new<\/span> consists of two steps.<\/p>\n\n- Allocate the memory for the object<\/li>\n
- Constructing the object into the allocated memory<\/li>\n<\/ol>\n
operator new<\/span> or operator new []<\/span><\/a> makes the first step; the constructor the second step.<\/p>\nThe same strategy applies to the destruction but the other way around. First, the destructor is called (if any), and then the memory is deallocated with operator delete<\/span> or operator delete []<\/span><\/a>. This two-step creation and destruction is the reason for the four rules. So, let’s start.<\/p>\nR.10: Avoid malloc()<\/code> and free()<\/code><\/a><\/h3>\nWhat is the difference between new<\/span> and malloc<\/span>, or delete<\/span> and free<\/span>? The C-functions malloc<\/span> and free<\/span> do only half of the job. malloc<\/span> allocates the memory and free<\/span> only deallocates the memory. Neither does malloc<\/span> invoke the constructor, nor does free invoke the destructor.<\/p>\nThis means if you use an object which was just created<\/em> via malloc,<\/span> you will get undefined behavior.<\/p>\n\n\/\/ mallocVersusNew.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n\r\nstruct<\/span> Record{\r\n Record(std::<\/span>string na =<\/span> \"Record\"<\/span>):<\/span> name(na){} \/\/ (4)<\/span>\r\n std::<\/span>string name;\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n Record*<\/span> p1 =<\/span> static_cast<\/span><<\/span>Record*><\/span>(malloc(sizeof<\/span>(Record))); \/\/ (1)<\/span>\r\n std::<\/span>cout <<<\/span> p1-><\/span>name <<<\/span> std::<\/span>endl; \/\/ (3)<\/span>\r\n\r\n auto<\/span> p2 =<\/span> new<\/span> Record; \/\/ (2)<\/span>\r\n std::<\/span>cout <<<\/span> p2-><\/span>name <<<\/span> std::<\/span>endl; <\/span>\r\n \r\n std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n \r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
I only allocate in (1) memory for my Record<\/span> object. The result is that the output p1->name<\/span> in (3) is undefined behavior. In contrast, call (2) invokes the constructor in line (4). Undefined behavior means that you can not make any assumptions about the program’s output.<\/p>\nDepending on the used platform and the used GCC, the result of the program is entirely different.<\/p>\n
\n- GCC 4.8.5 produces a core dump on my local PC<\/li>\n<\/ul>\n
![\"mallocVersusNewGcc\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/12\/mallocVersusNewGcc.png\")
<\/p>\n
\n- GCC 4.9 (on cppreference.com) produces no output<\/li>\n<\/ul>\n
![\"mallocVersusNewOnline49\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/12\/mallocVersusNewOnline49.png\")
<\/p>\n
\n- GCC 7.1 (cppreference.com) produces the expected<\/em> output<\/li>\n<\/ul>\n
![\"mallocVersusNewOnline71\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/12\/mallocVersusNewOnline71.png\")
<\/p>\n
R.11: Avoid calling new<\/code> and delete<\/code> explicitly<\/a><\/h3>\nYou should keep this rule in mind. The emphasis in this rule lies on the word explicitly<\/strong> because using smart pointers or containers of the Standard Template Library gives you the object which use implicitly<\/strong> new<\/span> and delete.<\/span><\/p>\n<\/p>\nR.12: Immediately give the result of an explicit resource allocation to a manager object<\/a><\/h3>\nThis is the key idea of a smart pointer such as std::unique_ptr<int> upInt(new int()) and<\/span> will not hold in the counterexample from the guidelines. If the allocation of the buffer fails, the file handle will be lost.<\/p>\n\nvoid<\/span> f<\/span>(const<\/span> std::<\/span>string&<\/span> name)\r\n{\r\n FILE<\/span>*<\/span> f =<\/span> fopen(name, \"r\"<\/span>); \/\/ open the file<\/span>\r\n std::<\/span>vector<<\/span>char<\/span>><\/span> buf(1024<\/span>);\r\n fclose(f); \/\/ close the file<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
R.13: Perform at most one explicit resource allocation in a single expression statement<\/a><\/h3>\nThis rule is a little bit tricky.
<\/span><\/p>\n\nvoid<\/span> func<\/span>(std::<\/span>shared_ptr<<\/span>Widget><\/span> sp1, std::<\/span>shared_ptr<<\/span>Widget><\/span> sp2){\r\n ...\r\n}\r\n\r\nfunc(std::<\/span>shared_ptr<<\/span>Widget><\/span>(new<\/span> Widget(1)), std::<\/span>shared_ptr<<\/span>Widget><\/span>(new<\/span> Widget(2)));\r\n<\/pre>\n<\/div>\n <\/p>\n
This function call is not exception-safe and may result in a memory leak. Why? The reason is that four operations must be performed to initialize the shared pointers.<\/p>\n
\n- Allocate memory for Widget(1)<\/span><\/li>\n
- Construct Widget(1)<\/span><\/li>\n
- Allocate memory for Widget(2)<\/span><\/li>\n
- Construct Widget(2)<\/span><\/li>\n<\/ol>\n
The compiler can allocate the memory for Widget(1)<\/span> and Widget(2)<\/span> and then construct both.<\/p>\n\n- Allocate memory for Widget(1)<\/span><\/li>\n
- Allocate memory for Widget(2)<\/span><\/li>\n
- Construct Widget(1)<\/span><\/li>\n
- Construct Widget(2)<\/span><\/li>\n<\/ol>\n
If one of the constructors throws an exception, the memory of the other object will not be automatically freed, and we will get a memory leak.<\/p>\n
It’s easy to overcome this issue using the factory function std::make_shared to create a std::shared_ptr. <\/span>
<\/span><\/p>\n\nfunc(std::<\/span>make_shared<<\/span>Widget><\/span>(1<\/span>), std::<\/span>make_shared<<\/span>Widget><\/span>(2<\/span>));\r\n<\/pre>\n<\/div>\n <\/p>\n
std::make_shared<\/span> guarantees that the function will have no effect if an exception is thrown. The pendant function std::make_unique<\/span> for creating a std::unique_ptr<\/span> guarantees the same. <\/p>\nWhat’s next?<\/h2>\n