{"id":5944,"date":"2020-07-11T08:32:03","date_gmt":"2020-07-11T08:32:03","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-20-static-initialization-order-fiasco\/"},"modified":"2023-06-26T09:47:23","modified_gmt":"2023-06-26T09:47:23","slug":"c-20-static-initialization-order-fiasco","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-20-static-initialization-order-fiasco\/","title":{"rendered":"Solving the Static Initialization Order Fiasco with C++20"},"content":{"rendered":"

According to the FAQ of isocpp.org<\/a> is the static initialization order fiasco “a subtle way to crash your program”. <\/em>The FAQ continues: The static initialization order problem is a very subtle and commonly misunderstood aspect of C++. <\/em>“. Today, I write about this very subtle and misunderstood aspect of C++.  
<\/span><\/p>\n

<\/p>\n

\"TimelineCpp20\"<\/p>\n

My short Disclaimer<\/h2>\n

Before I continue, I want to make a short disclaimer. Today’s post is about variables with static storage duration and their dependencies. Variables with static storage duration may be global (namespace) variables, static variables, or static class members. In short, I call them static variables. Dependencies on static variables in different translation units are generally a code smell<\/a> and should be a reason for refactoring.<\/strong> Consequently, if you follow my advice to refactor, you can skip the rest of this post. <\/p>\n<\/p>\n

Static Initialization Order Fiasco<\/h2>\n

Static variables in one translation unit are initialized according to their definition order.<\/p>\n

In contrast, the initialization of static variables between translation units has a severe issue. When one static variable staticA<\/span> is defined in one translation unit and another static variable staticB<\/span> is defined in another, and staticB<\/span> needs staticA<\/span> to initialize itself, you end with the static initialization order fiasco. The program is ill-formed because you have no guarantee which static variable is initialized first at run-time (dynamic).<\/p>\n

Before discussing the rescue, let me show you the static initialization order fiasco.<\/p>\n

A 50:50 Chance to get it Right<\/h3>\n

What is unique about the initialization of static variables? The initialization of static variables happens in two steps: static and dynamic. <\/p>\n

When a static cannot be const-initialized<\/a> during compile-time, it is zero-initialized<\/a>. At run-time, the dynamic initialization happens for these statics that is zero-initialized<\/a> at compile-time. <\/p>\n

 <\/p>\n

\n
\/\/ sourceSIOF1.cpp<\/span>\r\n\r\nint<\/span> quad<\/span>(int<\/span> n) {\r\n    return<\/span> n *<\/span> n;\r\n}\r\n\r\nauto<\/span> staticA  =<\/span> quad(5<\/span>); \r\n<\/pre>\n<\/div>\n
 <\/p>\n
\n
\/\/ mainSOIF1.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nextern<\/span> int<\/span> staticA;   \/\/ (1)<\/span>\r\nauto<\/span> staticB =<\/span> staticA;\r\n\r\nint<\/span> main<\/span>() {\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    std::<\/span>cout <<<\/span> \"staticB: \"<\/span> <<<\/span> staticB <<<\/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
Line (1) declares the static variable staticA<\/span>. The initialization of staticB<\/span> depends on the initialization of staticA<\/span>. staticB<\/span> is zero-initialized at compile-time and dynamically initialized at run-time. The issue is that there is no guarantee in which order staticA<\/span> or staticB <\/span>are initialized. staticA <\/span>and staticB<\/span> belong to different translation units. You have a 50:50 chance that staticB<\/span> is 0 or 25. <\/p>\n
To make my observation visible, I change the link order of the object files. This also changes the value for staticB!<\/span><\/p>\n
 \"StaticInitializationOrderFiasco\"<\/p>\n
What a fiasco!  The result of the executable depends on the link order of the object files. What can we do when we don’t have C++20 at our disposal? <\/p>\n
Lazy Initialization of static with local scope<\/h3>\n
Static variables with the local scope are created when used for the first time. Local scope essentially means that the static variable is surrounded in some way by curly braces. This lazy creation is a guarantee that C++98 provides. With C++11, static variables with the local scope are also initialized in a thread-safe way. The thread-safe Meyers Singleton is based on this additional guarantee. I already wrote a post about the “Thread-Safe Initialization of a Singleton<\/a>“. <\/p>\n
Lazy initialization can also be used to overcome the static initialization order fiasco.<\/p>\n
\n
\/\/ sourceSIOF2.cpp<\/span>\r\n\r\nint<\/span> quad<\/span>(int<\/span> n) {\r\n    return<\/span> n *<\/span> n;\r\n}\r\n\r\nint<\/span>&<\/span> staticA() {\r\n    \r\n    static<\/span> auto<\/span> staticA  =<\/span> quad(5<\/span>);   \/\/ (1)<\/span>\r\n    return<\/span> staticA;\r\n    \r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
\n
\/\/ mainSOIF2.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nint<\/span>&<\/span> staticA();           \/\/ (2)<\/span>\r\n\r\nauto<\/span> staticB =<\/span> staticA(); \/\/ (3)<\/span>\r\n\r\nint<\/span> main<\/span>() {\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    std::<\/span>cout <<<\/span> \"staticB: \"<\/span> <<<\/span> staticB <<<\/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
staticA<\/span> is, in this case, static in a local scope (1). Line (2) declares the function staticA<\/span>, which is used to initialize in the following line staticB<\/span>. This local scope of staticA<\/span> guarantees that staticA<\/span> is created and initialized during run-time when it is the first time used. Changing the link order can, in this case, not change the value of staticB.<\/span><\/p>\n
\"StaticInitializationOrderFiascoMeyers\"<\/p>\n
Now, I solve the static initialization order fiasco using C++20.<\/p>\n
Compile-time initialization of a static<\/h3>\n
Let me apply constinit<\/span> to staticA<\/span>. constinit<\/span> guarantees that staticA<\/span> is initialized during compile-time.<\/p>\n
 <\/p>\n
\n
\/\/ sourceSIOF3.cpp<\/span>\r\n\r\nconstexpr int<\/span> quad<\/span>(int<\/span> n) {\r\n    return<\/span> n *<\/span> n;\r\n}\r\n\r\nconstinit auto<\/span> staticA  =<\/span> quad(5<\/span>);  \/\/ (2)<\/span>\r\n<\/pre>\n<\/div>\n
 <\/p>\n
\n
\/\/ mainSOIF3.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n\r\nextern<\/span> constinit int<\/span> staticA;     \/\/ (1)<\/span>\r\n\r\nauto<\/span> staticB =<\/span> staticA;\r\n\r\nint<\/span> main<\/span>() {\r\n    \r\n    std::<\/span>cout <<<\/span> std::<\/span>endl;\r\n    \r\n    std::<\/span>cout <<<\/span> \"staticB: \"<\/span> <<<\/span> staticB <<<\/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
(1) declares the variable staticA<\/span>. staticA<\/span> (2) is initialized during compile-time. By the way, using constexpr<\/span> in (1) instead of constinit<\/span> is not valid because constexpr<\/span> requires a definition and not just a declaration. <\/p>\n
 <\/p>\n
Thanks to Clang 10 compiler, I can execute the program.<\/p>\n
\"StaticInitializationOrderFiascoConstinit\"<\/p>\n
As in the case of the lazy initialization with a local static, staticB<\/span> has the value 25.<\/p>\n
What’s next?<\/h2>\n
C++20 has a few small improvements around Templates and Lambdas. In my next post,<\/a> I will present which ones.<\/p>\n
 <\/p><\/p>\n","protected":false},"excerpt":{"rendered":"
According to the FAQ of isocpp.org is the static initialization order fiasco “a subtle way to crash your program”. The FAQ continues: The static initialization order problem is a very subtle and commonly misunderstood aspect of C++. “. Today, I write about this very subtle and misunderstood aspect of C++.  <\/p>\n","protected":false},"author":21,"featured_media":5199,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[375],"tags":[461,460],"class_list":["post-5944","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-c-20","tag-constinit","tag-initialization"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5944","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=5944"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5944\/revisions"}],"predecessor-version":[{"id":6733,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5944\/revisions\/6733"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/5199"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5944"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5944"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5944"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}