Your program can fail before main

Invisible startup work deserves distrust. Objects with static storage duration in different translation units are initialized in an order the program does not control.

Constant initialization is safe when the compiler can complete it before dynamic startup, but a constructor that reads another translation unit crosses into an ordering regime the source file does not reveal. The dependency graph exists at runtime while the type system and build graph remain silent. Link order, archive extraction, build flags, and refactoring can change the observed sequence without changing either constructor.

When one global depends on another global from a different translation unit, construction can run too early and fail before main has a chance to establish the system.

The symptom is often misleading: an empty registry, a default-initialized mutex wrapper, a logger that drops the first message, or a crash inside allocator and runtime code. The reproduction may disappear under a different linker or test binary because the implementation changed object ordering, not because the bug was fixed. Destruction has the mirror-image risk when one global uses another after its lifetime ended.

The practical move is simple: put the dependency behind a function-local static. Construct on first use. Make lifetime explicit. Never let the linker decide your boot sequence.

Since C++11, initialization of a function-local static is synchronized. That makes the first-use boundary explicit and testable, but it does not absolve the design from cycle analysis or teardown policy. For infrastructure registries and process-lifetime services, an intentionally leaked immutable instance can be safer than an elaborate destruction graph. For everything else, prefer explicit ownership passed from main so startup and shutdown order appear in ordinary control flow.