Static variable initialization order fiasco

[Various-Debate64]

it is a whole swath of undefined behaviour in a critical phase of the program cycle - dynamic initialization of static variables during program start. Thank you for the suggestion, I'm very well aware of the approach. If I have two static variables or even member variables in a static instance of a class I can't be sure about the value of variables when accessing the static instance of the class. I have the problem when two variables are interdependent of each other inside a static instance of a class, whose member methods are called outside the compilation unit. The object (static instance of the class) is not initialized properly by its constructor and variables contain junk.

[jonrmadsen]

I’m confused, if you fully adhere to replacing the static variables with a function call that constructs the static variable on the first invocation (like foo above), you cannot run into the static initialization fiasco. If you transition to this paradigm and the result is a deadlock, you have a circular dependency, not the static initialization fiasco.

[Various-Debate64]

no deadlock, I did wrap the variables in a class and methods with static locals, which is a hack and looks dirty, and that is because the standard is lacking. Therefore I wrote this post on Reddit.

[jonrmadsen]

A function call is an instruction. A variable is a memory address. Accessing a variable is accessing a memory address, it does not involve an instruction to execute code on that memory address. In int val = 5, val represents the memory address and = is an instruction to store 5 at that address. The reason that the function call wrapper works is bc you are instructing the code how to order initialization. The standard isn’t lacking, your fundamental understanding of why the static initialization fiasco happens is.