{"id":4977,"date":"2016-10-11T06:13:40","date_gmt":"2016-10-11T06:13:40","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/initialization\/"},"modified":"2023-06-26T12:40:05","modified_gmt":"2023-06-26T12:40:05","slug":"initialization","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/initialization\/","title":{"rendered":"{}-Initialization"},"content":{"rendered":"

The initialization of variables was unified in C++11. The rule is quite simple. {}-Initialization is always applicable. <\/p>\n

<\/p>\n

Always applicable<\/h2>\n

For simplicity reasons I will speak in the rest of the post about {}-Initialization, although I mean uniformed initialization with {}. But before I speak about two crucial implications of the {}-Initialization in safety-critical software I will show a few special use cases. This uses cases that require C++11.<\/p>\n

<\/p>\n

\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41\r\n42\r\n43\r\n44\r\n45\r\n46\r\n47\r\n48\r\n49\r\n50\r\n51\r\n52\r\n53\r\n54\r\n55<\/pre>\n<\/td>\n
\n
\/\/ uniformInitialization.cpp<\/span>\r\n\r\n#include <map><\/span>\r\n#include <vector><\/span>\r\n#include <string><\/span>\r\n\r\n\/\/ Initialization of a C-Array as attribute of a class<\/span>\r\nclass<\/span> Array<\/span>{\r\n  public:\r\n    Array(): myData{1,2,3,4,5}{}    \r\n  private<\/span>:\r\n    int<\/span> myData[5];\r\n};\r\n\r\nclass<\/span> MyClass<\/span>{\t\t\t\r\n  public<\/span>: \r\n    int<\/span> x;\r\n    double<\/span> y;\r\n};\r\n\r\nclass<\/span> MyClass2<\/span>{\t\t\r\n  public<\/span>:\r\n    MyClass2(int<\/span> fir, double<\/span> sec):x{fir},y{sec} {};\r\n  private: \r\n    int<\/span> x;\r\n    double<\/span> y;\r\n};\r\n\r\nint<\/span> main(){\r\n\r\n  \/\/ Direct Initialization of a standard container<\/span>\r\n  int<\/span> intArray[]= {1,2,3,4,5};   \r\n  std::vector<int<\/span>> intArray1{1,2,3,4,5};  \r\n  std::map<std::string,int<\/span>> myMap{{\"Scott\"<\/span>,1976}, {\"Dijkstra\"<\/span>,1972}};\r\n\r\n  \/\/ Initialization of a const heap array<\/span>\r\n  const<\/span> float<\/span>* pData= new<\/span> const<\/span> float<\/span>[3]{1.1,2.2,3.3};\r\n\r\n  Array arr;\r\n\r\n  \/\/ Defaut Initialization of a arbitrary object   <\/span>\r\n  int<\/span> i{};                \/\/ i becomes 0<\/span>\r\n  std::string s{};        \/\/ s becomes \"\"<\/span>\r\n  std::vector<float<\/span>> v{}; \/\/ v becomes an empty vector<\/span>\r\n  double<\/span> d{};             \/\/ d becomes 0.0<\/span>\r\n\t\r\n  \/\/ Initializations of an arbitrary object using public attributes\t<\/span>\r\n  MyClass myClass{2011,3.14};      \r\n  MyClass myClass1= {2011,3.14};    \r\n\r\n  \/\/ Initializations of an arbitrary object using the constructor<\/span>\r\n  MyClass2 myClass2{2011,3.14};     \r\n  MyClass2 myClass3= {2011,3.14};   \r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
First things first. The direct initialization of the C array, the std::vector,<\/span> and the std::map<\/span> (lines 32 – 34) is relatively easy. In the case of the std::map<\/span>, the inner {}-pairs are the key and value pairs. The following particular use case is the direct initialization of a const<\/span> C array on the heap (line 36). Special about the array arr <\/span>in line 39 is that C arrays can be directly initialized in the constructor initializer (line 10). The default initialization in lines 42 to 45 looks entirely innocent. But if I use round brackets instead of curly brackets, the most vexing parse will happen. That does not sound good. Why? Wait for the next section. I directly initialize in lines 48 and 49 the public attributes of the objects. It’s also possible to call the constructor with curly braces (lines 52 and 53).<\/p>\n<\/p>\n
auto<\/h3>\n
Always applicable? Yes, but you have to keep a particular rule in mind. If you use automatic type deduction with auto<\/span> in combination with an {}-initialization, you will get a std::initializer_list.<\/span><\/p>\n
<\/p>\n
\n
  auto<\/span> initA{1};          \/\/ std::initializer_list<int><\/span>\r\n  auto<\/span> initB= {2};        \/\/ std::initializer_list<int><\/span>\r\n  auto<\/span> initC{1, 2};       \/\/ std::initializer_list<int><\/span>\r\n  auto<\/span> initD= {1, 2};     \/\/ std::initializer_list<int>
<\/span>\r\n<\/pre>\n<\/div>\n
This behavior will change very likely in C++17.<\/p>\n
<\/p>\n
\n
  auto<\/span> initA{1};          \/\/ int<\/span>\r\n  auto<\/span> initB= {2};        \/\/ std::initializer_list<int><\/span>\r\n  auto<\/span> initC{1, 2};       \/\/ error, no single element<\/span>\r\n  auto<\/span> initD= {1, 2};     \/\/ std::initializer_list<int><\/span>\r\n<\/pre>\n<\/div>\n
 <\/p>\n
I don’t like this change. The C++11 semantic is quite clear to me. I will get an initializer list if I use {}-initialization with auto. With C++17, I have to keep the two exceptions with auto<\/span> in my head.<\/p>\n
    \n
  1. It makes a difference if you use direct or copy initialization.<\/li>\n
  2. It makes a difference if you use {}-initialization with one or more elements.<\/li>\n<\/ol>\n
    Most vexing parse<\/h2>\n
    But what does that mean? It seems to be a well-known expression: https:\/\/en.wikipedia.org\/wiki\/Most_vexing_parse<\/a>.  The story is quickly told. Most C++ developers know them personally.  <\/a><\/p>\n
    At first, a small program shows the issue.<\/p>\n
    <\/p>\n
    \n\n\n\n
    \n
     1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20<\/pre>\n<\/td>\n
    		\n
    \/\/ parse.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nstruct<\/span> MyInt{\r\n  MyInt(int<\/span> i):i(i){}\r\n  MyInt():i(0){}\r\n  int<\/span> i;\r\n};\r\n\r\n\r\nint<\/span> main(){\r\n\r\n  MyInt myInt(2011);\r\n  MyInt myInt2();\r\n  \r\n  std::cout << myInt.i << std::endl;\r\n  std::cout << myInt2.i << std::endl;\r\n \r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
     <\/p>\n
    MyInt<\/span> in lines 5 – 9 is a simple wrapper for the natural number i. The constructor in line 6 sets i to an explicit value. Conversely, the default constructor in line 7 sets i to 0. So far, so good. I use both constructors in lines 14 and 15 and display the values of i. Compile and run; that’s all I have to do.<\/p>\n
    But wait. The program does not compile.<\/p>\n
     \"parse\"<\/p>\n
    The error message is not so meaningful. The compiler can interpret the expression in line 15 as a call of a constructor or as a declaration of a function. In case of doubt, it interprets the expression as a function declaration. The slightly modified program shows it.<\/p>\n
    <\/p>\n
    \n\n\n\n
    \n
     1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22<\/pre>\n<\/td>\n
    		\n
    \/\/ parseResolved.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <typeinfo><\/span>\r\n\r\nstruct<\/span> MyInt{\r\n  MyInt(int<\/span> i):i(i){}\r\n  MyInt():i(0){}\r\n  int<\/span> i;\r\n};\r\n\r\nMyInt myFunction();\r\n\r\nint<\/span> main(){\r\n\r\n  MyInt myInt(2011);\r\n  MyInt myInt2();\r\n  \r\n  std::cout << typeid<\/span>(myInt2).name() << std::endl;\r\n  std::cout << typeid<\/span>(myFunction).name() << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
     <\/p>\n
    I declare in line 12 the function myFunction<\/span> that has no arguments and returns a type MyInt.<\/span> myFunction<\/span> has the same signature as the function declarations in line 17. Thanks to the typeid<\/span> operator, the program’s output shows precisely that.<\/p>\n
    \"parseResolved\"<\/p>\n
    The solutions to the problem are quite easy. If I use curly braces in lines 12 and 17, the compiler will not interpret both lines as the function declaration. I already used this characteristic of the {}-initialization in the first example of this post (line 42 – 45).<\/p>\n
    But now the main topic of this post, which is so precious for software in safety-critical systems: preventing narrowing.<\/p>\n
    Preventing narrowing<\/h2>\n
    Narrowing or, more precisely, narrowing conversion is an implicit conversion of arithmetic values, including a loss of accuracy. That sounds extremely dangerous.<\/p>\n
    The following example shows the issue with the classical initialization for fundamental types. It doesn’t matter whether I use direct initialization or assignment.<\/p>\n
    \n\n\n\n
    \n
     1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17<\/pre>\n<\/td>\n
    		\n
    \/\/ narrowing.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nint<\/span> main(){\r\n\r\n  char<\/span> c1(999);     \r\n  char<\/span> c2= 999;\r\n  std::cout << \"c1: \"<\/span> << c1 << std::endl;\r\n  std::cout << \"c2: \"<\/span> << c2 << std::endl;\r\n  \r\n  int<\/span> i1(3.14); \r\n  int<\/span> i2= 3.14;\r\n  std::cout << \"i1: \"<\/span> << i1 << std::endl;\r\n  std::cout << \"i2: \"<\/span> << i2 << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
     <\/p>\n
    The output of the program shows two issues. First, the int<\/span> literal 999 doesn’t fit into the type char;<\/span> second, the double<\/span> literal doesn’t fit into the int<\/span> type.<\/p>\n
    \"narrowingUndefined\"<\/p>\n
    That is not possible with {}-initialization.<\/p>\n
    <\/p>\n
    \n\n\n\n
    \n
     1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17<\/pre>\n<\/td>\n
    		\n
    \/\/ narrowingSolved.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nint<\/span> main(){\r\n\r\n  char<\/span> c1{999};     \r\n  char<\/span> c2= {999};\r\n  std::cout << \"c1: \"<\/span> << c1 << std::endl;\r\n  std::cout << \"c2: \"<\/span> << c2 << std::endl;\r\n  \r\n  int<\/span> i1{3.14}; \r\n  int<\/span> i2= {3.14};\r\n  std::cout << \"i1: \"<\/span> << i1 << std::endl;\r\n  std::cout << \"i2: \"<\/span> << i2 << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
     <\/p>\n
    The program is ill-formed because of the narrowing with {}-Initialization the compiler has at least to diagnose a warning. Although the program is ill-formed, the compiler has not rejected it.<\/p>\n
    But now, the maximum confusion with GCC begins. It makes a difference whether I use GCC 4.7 or GCC 4.8. GCC 4.7 rejected the program; GCC 4.8 only provides a warning. With GCC 5.1 we get an error. Don’t you believe me? Try it out with the online compiler https:\/\/gcc.godbolt.org\/<\/a>. The clang++ compiler is much more predictable. Therefore my tip. Compile your program in such a way that narrowing is an error.<\/strong> So did I. I used the flag -Werror=narrowing<\/span>, and GCC 4.8 complains about the program.<\/p>\n
     \"narrowing\"<\/p>\n
    A small remark at the end. The expression char c3{8}<\/span> is indeed no narrowing because eight fits the type char. The same holds for char c3= {8}.<\/span><\/p>\n
    What’s next?<\/span><\/h2>\n
    C++11 got with static_assert<\/span> the type-traits library two powerful features for checking the source code at compile time. In the next post, <\/a>I will have a deeper look into static_assert<\/span> and its combination with the functions of the type-traits library.<\/p>\n
     <\/p>\n
     <\/p>\n
     <\/p>\n
     <\/p>\n
     <\/p>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    The initialization of variables was unified in C++11. The rule is quite simple. {}-Initialization is always applicable. <\/p>\n","protected":false},"author":21,"featured_media":4973,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[364],"tags":[460],"class_list":["post-4977","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-embedded","tag-initialization"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4977","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=4977"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4977\/revisions"}],"predecessor-version":[{"id":6938,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/4977\/revisions\/6938"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/4973"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=4977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=4977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=4977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}