{"id":6502,"date":"2023-01-22T18:49:43","date_gmt":"2023-01-22T18:49:43","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/rule-of-zero-or-six\/"},"modified":"2023-08-20T14:37:05","modified_gmt":"2023-08-20T14:37:05","slug":"rule-of-zero-or-six","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/rule-of-zero-or-six\/","title":{"rendered":"The Rule of Zero, or Six"},"content":{"rendered":"

The rule of zero, or six, is one of the advanced rules in modern C++. I wrote in my current book “C++ Core Guidelines Explained: Best Practices for Modern C++<\/a>” about them. Today, I want to quote the relevant parts of my book in this post.<\/p>\n

<\/p>\n

 <\/p>\n

 \"classes\"<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 Cippie reasons about the rule of zero, five, or six<\/em>.<\/p>\n

 <\/p>\n

By default, the compiler can generate the big six if needed. You can define the six special member functions, but can also ask explicitly the compiler to provide them with = default<\/code> or delete them with = delete<\/code>.<\/p>\n

C.20: If you can avoid defining any default operations, do<\/a><\/h2>\n

This rule is also known as “the rule of zero<\/strong>“. That means, that you can avoid writing any custom constructor, copy\/move constructors, assignment operators, or destructors by using types that support the appropriate copy\/move semantics. This applies to the regular types such as the built-in types bool<\/code> or double<\/code>, but also the containers of the Standard Template Library (STL)such as std::vector<\/code> or std::string<\/code>.<\/p>\n

<\/p>\n

\n
class<\/span> Named_map<\/span> {\r\n public:<\/span>\r\n    \/\/ ... no default operations declared ...<\/span>\r\n private:<\/span>\r\n    std::<\/span>string name;\r\n    std::<\/span>map<<\/span>int<\/span>, int<\/span>><\/span> rep;\r\n};\r\n\r\nNamed_map nm;       \/\/ default construct<\/span>\r\nNamed_map nm2{nm};  \/\/ copy construct<\/span>\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The default construction and the copy construction work because they are already defined for std::string<\/code> and std::map<\/code>. When the compiler auto-generates the copy constructor for a class, it invokes the copy constructor for all members and all bases of the class.<\/p>\n
C.21: If you define or =delete<\/code> any default operation, define or =delete<\/code> them all<\/a><\/h2>\n
The big six are closely related. Due to this relation, you have to define or =delete<\/code> all six. Consequently, this rule is called “the rule of six<\/strong>“. Sometimes, you hear “the rule of five<\/strong>“, because the default constructor is special, and, therefore, sometimes excluded.<\/p>\n
Dependencies between the special member functions<\/h3>\n
Howard Hinnant developed in his talk at the ACCU 2014<\/a> conference an overview to the automatically generated special member functions.<\/p>\n
\"DefaultDelete\"<\/p>\n
 <\/p>\n
 Automatically generated special member functions<\/em><\/p>\n
Howard’s table demands a deep explanation.<\/p>\n
First of all, user-declared means for one of these six special member functions that you define it explicitly or auto request it from the compiler with =default<\/code>. Deletion of the special member function with =delete<\/code> is also regarded as user declared. Essentially, when you just use the name, such the name of the default constructor, it counts as user declared.<\/p>\n
When you define any constructor, you get no default constructor. A default constructor is a constructor which can be invoked without an argument.<\/p>\n
When you define or delete a default constructor with =default<\/code> or =delete<\/code>, no other of the six special member functions is affected.<\/p>\n
When you define or delete a destructor, a copy constructor, or a copy-assignment operator with =default<\/code> or =delete<\/code>, you get no compiler-generated move-constructor and move-assignment constructor. This means move operations such as move construction or move assignment fall back to copy operations such as copy construction or copy assignment. This fallback automatism is marked in red in the table.<\/p>\n
    When you define or delete with =default<\/code> or =delete a move constructor or a move assignment operator, you get only the defined =default<\/code> or =delete<\/code> move constructor or move assignment operator. Consequently, the copy constructor and the copy assignment operator are set to =delete<\/code>. Invoking a copy operation such as copy construction or copy assignment causes, therefore, a compilation error.<\/p>\n
When you don’t follow this rule, you get very unintuitive objects. Here is an unintuitive example from the guidelines.<\/p>\n
 <\/p>\n
<\/p>\n
\n
\/\/ doubleFree.cpp<\/span>\r\n\r\n#include <cstddef><\/span>\r\n\r\nclass<\/span> BigArray<\/span> {\r\n\r\n public:<\/span>\r\n    BigArray(std::<\/span>size_t<\/span> len):<\/span> len_(len), data_(new<\/span> int<\/span>[len]) {}\r\n\r\n    ~<\/span>BigArray(){\r\n        delete<\/span>[] data_;\r\n    }\r\n\r\n private:<\/span>\r\n  size_t<\/span> len_;\r\n  int<\/span>*<\/span> data_;\r\n};\r\n\r\nint<\/span> main<\/span>(){\r\n  \r\n    BigArray bigArray1(1000<\/span>);\r\n    \r\n    BigArray bigArray2(1000<\/span>);\r\n    \r\n    bigArray2 =<\/span> bigArray1;    \/\/ (1)<\/span><\/em>\r\n\r\n}                             \/\/ (2)\r\n<\/span><\/em><\/pre>\n<\/div>\n
 <\/p>\n
Why does this program have undefined behavior? The default copy assignment operation bigArray2 = bigArray1<\/code> (1) of the example copies all members of bigArray2<\/code>. Copying means, in particular, that pointer data is copied but not the data. Hence, the destructor for bigArray1<\/code> and bigArray2<\/code> is called (2), and we get undefined behavior because of double free.<\/p>\n
The unintuitive behavior of the example is, that the compiler-generated copy assignment operator of BigArray<\/code> makes a shallow copy of BigArray, but the explicitly implemented destructor of BigArray<\/code> assumes ownership of data.<\/p>\n
AddressSanitizer<\/a> makes the undefined behavior visible.<\/p>\n
\"doubleFree\"<\/em><\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 Double free detected with Address Sanitizer<\/em><\/p>\n
 <\/p>\n<\/p>\n
C.22 Make default operations consistent<\/h2>\n
This rule is related to the previous rule. If you implement the default operations with different semantics, the users of the class may become very confused. This strange behavior may also appear if you partially implement the member functions and partially request them via =default<\/code>. You cannot assume that the compiler-generated special member functions have the same semantics as yours.<\/p>\n
As an example of the odd behavior, here is the class Strange<\/code>. Strange<\/code> includes a pointer to int<\/code>.<\/p>\n
 <\/p>\n
<\/span><\/p>\n
\n
\/\/ strange.cpp<\/span>

#include <iostream><\/span>

struct<\/span> Strange { \r\n  \r\n    Strange():<\/span> p(new<\/span> int<\/span>(2011<\/span>)) {}\r\n    \r\n    \/\/ deep copy <\/span>\r\n    Strange(const<\/span> Strange&<\/span> a) :<\/span> p(new<\/span> int<\/span>(*<\/span>a.p)) {}                 \/\/ (1)<\/span><\/em>\r\n  \r\n    \/\/ shallow copy<\/span>\r\n    \/\/ equivalent to Strange& operator = (const Strange&) = default;<\/span>\r\n    Strange&<\/span> operator<\/span> =<\/span> (const<\/span> Strange&<\/span> a) {                        \/\/ (2) <\/span> <\/em>         \r\n        p =<\/span> a.p;\r\n        return<\/span> *<\/span>this<\/span>;\r\n    }  \r\n   \r\n    int<\/span>*<\/span> p;\r\n    \r\n};\r\n\r\nint<\/span> main<\/span>() {\r\n  \r\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n  \r\n    std::<\/span>cout <<<\/span> \"Deep copy\"<\/span> <<<\/span> '\\n'<\/span>;\r\n  \r\n    Strange s1;\r\n    Strange s2(s1);                                               \/\/ (3)<\/span><\/em>                                   \r\n  \r\n    std::<\/span>cout <<<\/span> \"s1.p: \"<\/span> <<<\/span> s1.p <<<\/span> \"; *s1.p: \"<\/span> <<<\/span> *<\/span>s1.p <<<\/span> '\\n'<\/span>;\r\n    std::<\/span>cout <<<\/span> \"s2.p: \"<\/span> <<<\/span> s2.p <<<\/span> \"; *s2.p: \"<\/span> <<<\/span> *<\/span>s2.p <<<\/span> '\\n'<\/span>;\r\n  \r\n    std::<\/span>cout <<<\/span>  \"*s2.p = 2017\"<\/span> <<<\/span> '\\n'<\/span>;\r\n    *<\/span>s2.p =<\/span> 2017<\/span>;                                                  \/\/ (4) <\/span> <\/em>                           \r\n  \r\n    std::<\/span>cout <<<\/span> \"s1.p: \"<\/span> <<<\/span> s1.p <<<\/span> \"; *s1.p: \"<\/span> <<<\/span> *<\/span>s1.p <<<\/span> '\\n'<\/span>;\r\n    std::<\/span>cout <<<\/span> \"s2.p: \"<\/span> <<<\/span> s2.p <<<\/span> \"; *s2.p: \"<\/span> <<<\/span> *<\/span>s2.p <<<\/span> '\\n'<\/span>;\r\n  \r\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n  \r\n    std::<\/span>cout <<<\/span> \"Shallow copy\"<\/span> <<<\/span> '\\n'<\/span>;\r\n\r\n    Strange s3;\r\n    s3 =<\/span> s1;                                                       \/\/ (5)    <\/span> <\/em>                               \r\n  \r\n    std::<\/span>cout <<<\/span> \"s1.p: \"<\/span> <<<\/span> s1.p <<<\/span> \"; *s1.p: \"<\/span> <<<\/span> *<\/span>s1.p <<<\/span> '\\n'<\/span>;\r\n    std::<\/span>cout <<<\/span> \"s3.p: \"<\/span> <<<\/span> s3.p <<<\/span> \"; *s3.p: \"<\/span> <<<\/span> *<\/span>s3.p <<<\/span> '\\n'<\/span>;\r\n  \r\n  \r\n    std::<\/span>cout <<<\/span>  \"*s3.p = 2017\"<\/span> <<<\/span> '\\n'<\/span>;\r\n    *<\/span>s3.p =<\/span> 2017<\/span>;                                                  \/\/ (6)<\/em>     <\/span>                          \r\n  \r\n    std::<\/span>cout <<<\/span> \"s1.p: \"<\/span> <<<\/span> s1.p <<<\/span> \"; *s1.p: \"<\/span> <<<\/span> *<\/span>s1.p <<<\/span> '\\n'<\/span>;\r\n    std::<\/span>cout <<<\/span> \"s3.p: \"<\/span> <<<\/span> s3.p <<<\/span> \"; *s3.p: \"<\/span> <<<\/span> *<\/span>s3.p <<<\/span> '\\n'<\/span>;\r\n  \r\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n  \r\n    std::<\/span>cout <<<\/span> \"delete s1.p\"<\/span> <<<\/span> '\\n'<\/span>;                            \/\/ (7) <\/span> <\/em>\r\n    delete<\/span> s1.p;                                        \r\n  \r\n    std::<\/span>cout <<<\/span> \"s2.p: \"<\/span> <<<\/span> s2.p <<<\/span> \"; *s2.p: \"<\/span> <<<\/span> *<\/span>s2.p <<<\/span> '\\n'<\/span>; \/\/ (8)<\/span><\/em> \r\n    std::<\/span>cout <<<\/span> \"s3.p: \"<\/span> <<<\/span> s3.p <<<\/span> \"; *s3.p: \"<\/span> <<<\/span> *<\/span>s3.p <<<\/span> '\\n'<\/span>;\r\n  \r\n    std::<\/span>cout <<<\/span> '\\n'<\/span>;\r\n  \r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The class Strange<\/code> has a copy constructor (1) and a copy-assignment operator (2). The copy constructor applies deep copy, and the assignment operator applies shallow copy. By the way, the compiler-generated copy constructor or copy assignment operator also applies shallow copy. Most of the time, you want deep copy semantics (value semantics) for your types, but you probably never want to have different semantics for these two related operations. The difference is that deep copy semantics creates two new separate storage p(new int(*a.p))<\/code> while shallow copy semantics just copies the pointer p = a.p<\/code>. Let\u2019s play with the Strange types. The following figure shows the output of the program.<\/p>\n
\"strange\"<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 Output of strange.cpp<\/code><\/em><\/p>\n
Line 3 uses the copy constructor to create s2<\/code>. Displaying the addresses of the pointer and changing the value of the pointer s2.p<\/code> (line 4) shows that s1<\/code> and s2<\/code> are two distinct objects. This is not the case for s1<\/code> and s3<\/code>. The copy-assignment operation in line (5) performs a shallow copy. The result is that changing the pointer s3.p<\/code> (line 6) also affects the pointer s1.p<\/code> because both pointers refer to the same value.<\/p>\n
The fun starts if I delete the pointer s1.p<\/code> (line 7). Thanks to the deep copy, nothing bad happens to s2.p<\/code>, but the value of s3.p<\/code> becomes an invalid pointer. To be more precise: Dereferencing an invalid pointer such as in *s3.p<\/code> (line 8) is undefined behavior.<\/p>\n
What’s Next?<\/h2>\n
The idea of a regular type is deeply embodied in the Standard Template Library (STL). The idea goes back to Alexander Stephanov<\/a>, who is the creator of the STL. Let me write more about regular types in my next post.<\/p>\n
 <\/p>\n<\/p>\n
 <\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
The rule of zero, or six, is one of the advanced rules in modern C++. I wrote in my current book “C++ Core Guidelines Explained: Best Practices for Modern C++” about them. Today, I want to quote the relevant parts of my book in this post.<\/p>\n","protected":false},"author":21,"featured_media":6499,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[379],"tags":[494],"class_list":["post-6502","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-patterns","tag-move"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/6502","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=6502"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/6502\/revisions"}],"predecessor-version":[{"id":8107,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/6502\/revisions\/8107"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/6499"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=6502"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=6502"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=6502"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}