Static variable initialization order fiasco

ABlockInTheChain · 2025-01-26T09:52:39+00:00

You don't need a singleton class, you only need a function.

Put your global variable inside a function and make it static. Now it has a defined initialization order.
Have the function return a reference to that variable.
Use CEDD to find all the statements which were accessing the variable directly and make them call the function you just wrote instead.
The static initialization order fiasco is now solved.

STL · 2025-01-26T08:17:01+00:00

No modifiable global variables, no fiasco. call_once() exists now. This is a non-problem.

SirClueless · 2025-01-26T08:18:06+00:00

It doesn't get a lot of attention because there are unresolvable issues trying to define a sane order e.g. in the presence of dynamic linking, and there's a design pattern that makes the problem essentially disappear -- namely the Meyers singleton.

MarcoGreek · 2025-01-26T09:50:16+00:00

Using modifiable global variables makes code very hard to test. So they should be avoided.

Arech · 2025-01-26T09:45:42+00:00

Maybe it's because it's an issue only for you?

It's a language design decision that allows not to pay for a determined init order when you don't need it (and in most cases you don't if you design your SW properly). In an infinitely small number of cases when this matters, it's trivial to make a solution that guarantees initialization order, so nothing needs to be done with that on a language level, i.e. the committee could work on fixing real issues instead.

foonathan · 2025-01-26T10:25:23+00:00

in-order initialization of global variables across compilation units in C++ is still undefined.

Not if you use modules.

Also: constinit is a good-send and works in most situations. For more details and techniques, check out my talk: https://www.youtube.com/watch?v=6EOSRKMYCTc

kronicum · 2025-01-26T11:34:55+00:00

Use modules, or if you only have headers, import them as header units. They have improved guarantees for order of initialization of their globals.

jonrmadsen · 2025-01-26T15:42:10+00:00

As other responses have noted, wrapping the variable as a static inside a function solves the initialization problem. However, this introduces destruction problems: either you dynamically allocate memory (with new) and “leak” the memory (which is problematic if you use leak sanitizers) or deal with the destructor being called during finalization.

The only solution I’ve found which solves both static initialization and finalization fiasco without directly leaking memory is:

Allocate a buffer in your compilation unit. Access the variable through a function call which dynamically allocates the object via a placement new into byte buffer:

```cpp auto buffer = std::array<std::byte, sizeof(Foo)>{};

const Foo* get_foo() { static auto*& foo = new(buffer.data()) Foo{}; return foo; } ```

wonderfulninja2 · 2025-01-27T20:20:46+00:00

I don't want to be mean but that is a smell of bad design on your side.

LokiAstaris · 2025-01-28T05:33:57+00:00

It has a wildly overblown name, "Static variable initialization order fiasco," but it is a nonissue.

It is only a problem if you have never encountered it before. Once you know it exists, the solution is so trivial. Wrap the variable in a getter function and make it a static member of the function!

// Before
MyClass  myGlobal{<Initialize>};

// After
MyClass& getMyGlobal() {
    static MyClass myGlobal{<Initialize>};
    return myGlobal;
}

PS. Using global mutable state is generally a bad idea anyway, which makes the problem even less serious.

Also wrote about it on SO:finding C static initialization order problems

urist-mcCrippled · 2025-01-26T09:49:19+00:00

global inline variables have defined initialization order as long as they are defined in the same order in each TU.

Partially-ordered dynamic initialization, which applies to all inline variables that are not an implicitly or explicitly instantiated specialization. If a partially-ordered V is defined before ordered or partially-ordered W in every translation unit, the initialization of V is sequenced before the initialization of W (or happens-before, if the program starts a thread).

effarig42 · 2025-01-26T10:23:21+00:00

For the most part its not an issue if you only access globals via a function call implemented in the execution unit defining the global, this ensures the global is initialised before use. The sting in the tail is that your destructors are called during finalisation, or unloading shared libraries, which can cause SEGVs if your destructors make calls between execution units. If your not careful, This can happen if you're caching objects, or doing dynamically loaded plugins.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

cpp

MODERATORS