![\"stork](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/09\/stork-1324371_1280.png\")
<\/p>\nThe lifecycle of each object starts with its creation; therefore, this post will be about the thirteen most fundamental rules for objects: constructor rules.<\/p>\n
<\/p>\n
<\/p>\n
Twelve rules are too many for one post. Therefore, I will cover only the first eleven. Why not just ten rules? Because the eleventh rule is just too attractive. The remaining two are part of the next post. Here are the thirteen rules.<\/p>\n
<\/p>\n
explicit<\/code><\/a><\/li>\n- C.47: Define and initialize member variables in the order of member declaration<\/a><\/li>\n
- C.48: Prefer in-class initializers to member initializers in constructors for constant initializers<\/a><\/li>\n
- C.49: Prefer initialization to assignment in constructors<\/a><\/li>\n
- C.50: Use a factory function if you need \u201cvirtual behavior\u201d during initialization<\/a><\/li>\n
- C.51: Use delegating constructors to represent common actions for all constructors of a class<\/a><\/li>\n
- C.52: Use inheriting constructors to import constructors into a derived class that does not need further explicit initialization<\/a><\/li>\n<\/ul>\n
<\/p>\n
So, let’s look at the rules in detail. For further analysis, use the links to the rules.<\/p>\n
<\/span>C.40: Define a constructor if a class has an invariant<\/a><\/span><\/h3>\nAn invariant of an object is a characteristic of the object that should hold for its entire lifetime. The place to establish such an invariant is the constructor. An invariant can be a valid date.<\/p>\n
<\/p>\n
\nclass<\/span> Date<\/span> { \/\/ a Date represents a valid date<\/span>\r\n \/\/ in the January 1, 1900 to December 31, 2100 range<\/span>\r\n Date(int<\/span> dd, int<\/span> mm, int<\/span> yy)\r\n :<\/span>d{dd}, m{mm}, y{yy}\r\n {\r\n if<\/span> (!<\/span>is_valid(d, m, y)) throw<\/span> Bad_date{}; \/\/ enforce invariant<\/span>\r\n }\r\n \/\/ ...<\/span>\r\nprivate:<\/span>\r\n int<\/span> d, m, y;\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n<\/p>\n
<\/span>C.41: A constructor should create a fully initialized object<\/a><\/span><\/h3>\nThis rule is quite similar to the previous one. Accordingly, creating the fully initialized object is the job of the constructor. A class having an init<\/span> method is asking for trouble.<\/p>\n<\/p>\n
\nclass<\/span> X1<\/span> {\r\n FILE<\/span>*<\/span> f; \/\/ call init() before any other function<\/span>\r\n \/\/ ...<\/span>\r\npublic:<\/span>\r\n X1() {}\r\n void<\/span> init(); \/\/ initialize f<\/span>\r\n void<\/span> read<\/span>(); \/\/ read from f<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n\r\nvoid<\/span> f<\/span>()\r\n{\r\n X1 file;\r\n file.read(); \/\/ crash or bad read!<\/span>\r\n \/\/ ...<\/span>\r\n file.init(); \/\/ too late<\/span>\r\n \/\/ ...<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
The user might mistakenly invoke read<\/span> before init <\/span>or might forget to invoke init.
<\/span><\/p>\n<\/span>C.42: If a constructor cannot construct a valid object, throw an exception<\/a><\/span><\/h3>\nAccordingly to the previous rule: throw an exception if you can not construct a valid object. There is not much to add. If you work with an invalid object, you must check its state before its usage. This is highly error-prone. Here is an example from the guidelines:<\/p>\n
<\/p>\n
\nclass<\/span> X3<\/span> { \/\/ bad: the constructor leaves a non-valid object behind<\/span>\r\n FILE<\/span>*<\/span> f; \r\n bool<\/span> valid;\r\n \/\/ ...<\/span>\r\npublic:<\/span>\r\n X3(const<\/span> string&<\/span> name)\r\n :<\/span>f{fopen(name.c_str(), \"r\"<\/span>)}, valid{false<\/span>}\r\n {\r\n if<\/span> (f) valid =<\/span> true<\/span>;\r\n \/\/ ...<\/span>\r\n }\r\n\r\n bool<\/span> is_valid() { return<\/span> valid; }\r\n void<\/span> read(); \/\/ read from f<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n\r\nvoid<\/span> f<\/span>()\r\n{\r\n X3 file {\"Heraclides\"<\/span>};\r\n file.read(); \/\/ crash or bad read!<\/span>\r\n \/\/ ...<\/span>\r\n if<\/span> (file.is_valid()) {\r\n file.read();\r\n \/\/ ...<\/span>\r\n }\r\n else<\/span> {\r\n \/\/ ... handle error ...<\/span>\r\n }\r\n \/\/ ...<\/span>\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
<\/span>C.43: Ensure that a value type class has a default constructor<\/a><\/span><\/h3>\nA value type is a type that behaves like an int.<\/span> A value type is similar to a regular type. I wrote about value types and regular types in the post about concrete types<\/a>. Having a default constructor makes it easier to use your type. Many constructors of STL containers rely on the fact that your type has a default constructor. For example, for the value of an ordered associative container such as std::map<\/span>. If all the class members have a default constructor, the compiler will implicitly generate one for your class.<\/p>\n<\/span>C.44: Prefer default constructors to be simple and non-throwing<\/a><\/span><\/h3>\nError handling is a lot easier with default constructors that can not throw. The guidelines provide a simple example:<\/p>\n
<\/p>\n
<\/p>\n
\ntemplate<\/span><<\/span>typename<\/span> T><\/span>\r\n\/\/ elem is nullptr or elem points to space-elem element allocated using new<\/span>\r\nclass<\/span> Vector1<\/span> {\r\npublic:<\/span>\r\n \/\/ sets the representation to {nullptr, nullptr, nullptr}; doesn't throw<\/span>\r\n Vector1() noexcept {}\r\n Vector1(int<\/span> n) :<\/span>elem{new<\/span> T[n]}, space{elem +<\/span> n}, last{elem} {}\r\n \/\/ ...<\/span>\r\nprivate:<\/span>\r\n own<<\/span>T*><\/span> elem =<\/span> nullptr;\r\n T*<\/span> space =<\/span> nullptr;\r\n T*<\/span> last =<\/span> nullptr;\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
<\/span>C.45: Don\u2019t define a default constructor that only initializes data members; use member initializers instead<\/a><\/span><\/h3>\nThis is one of my favorite features of C++11. Initializing class members directly in the class body makes the writing of constructors a lot easier and sometimes obsolete. Class X1<\/span> classically defines its members (before C++11) and X2<\/span> in a preferred way. A nice side effect is that the compiler automatically generates the constructor for X2<\/span>.<\/p>\n<\/p>\n
\nclass<\/span> X1<\/span> { \/\/ BAD: doesn't use member initializers<\/span>\r\n string s;\r\n int<\/span> i;\r\npublic:<\/span>\r\n X1() :<\/span>s{\"default\"<\/span>}, i{1<\/span>} { }\r\n \/\/ ...<\/span>\r\n};\r\n\r\nclass<\/span> X2<\/span> {\r\n string s =<\/span> \"default\"<\/span>;\r\n int<\/span> i =<\/span> 1<\/span>;\r\npublic:<\/span>\r\n \/\/ use compiler-generated default constructor<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
<\/span>C.46: By default, declare single-argument constructors explicit<\/code><\/a><\/span><\/h3>\nThis is a crucial rule. Single-argument constructors are often called conversion constructors. If you make them not explicit, an implicit conversion may happen.<\/p>\n
<\/p>\n
\nclass<\/span> String<\/span> {\r\npublic:<\/span>\r\n explicit<\/span> String(int<\/span>); \/\/ explicit\r\n \/\/ String(int); \/\/ implicit\r\n};\r\n\r\nString s =<\/span> 10<\/span>; \/\/ error because of explicit
<\/span><\/pre>\n<\/div>\n <\/p>\n
The implicit conversion from int<\/span> to String<\/span> is impossible because the constructor is explicit. If instead of the explicit constructor, the out-commented implicit constructor were used, you would get a string of size 10<\/p>\n<\/span>C.47: Define and initialize member variables in the order of member declaration<\/a><\/span><\/h3>\nThe class members are initialized in the order of their declaration. If you initialize them in the constructor initializer in a different order, you may get surprised.<\/p>\n
<\/p>\n
\nclass<\/span> Foo<\/span> {\r\n int<\/span> m1;\r\n int<\/span> m2;\r\npublic:<\/span>\r\n Foo(int<\/span> x) :<\/span>m2{x}, m1{++<\/span>x} { } \/\/ BAD: misleading initializer order<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n\r\nFoo x<\/span>(1<\/span>); \/\/ surprise: x.m1 == x.m2 == 2<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n
<\/span>C.48: Prefer in-class initializers to member initializers in constructors for constant initializers<\/a><\/span><\/h3>\nIn-class initializer makes it a lot easier to define the constructors. Additionally, you can not forget to initialize a member.<\/p>\n
<\/p>\n
<\/p>\n
\nclass<\/span> X<\/span> { \/\/ BAD<\/span>\r\n int<\/span> i;\r\n string s;\r\n int<\/span> j;\r\npublic:<\/span>\r\n X() :<\/span>i{666<\/span>}, s{\"qqq\"<\/span>} { } \/\/ j is uninitialized<\/span>\r\n X(int<\/span> ii) :<\/span>i{ii} {} \/\/ s is \"\" and j is uninitialized<\/span>\r\n \/\/ ...<\/span>\r\n};\r\n\r\nclass<\/span> X2<\/span> {\r\n int<\/span> i {666<\/span>};\r\n string s {\"qqq\"<\/span>};\r\n int<\/span> j {0<\/span>};\r\npublic:<\/span>\r\n X2() =<\/span> default<\/span>; \/\/ all members are initialized to their defaults<\/span>\r\n X2(