全局const对象构造函数体的执行时机及调用函数的行为合法性问题

你观察到的现象完全是标准要求的合法行为，绝非当前平台特有的偶发兼容 #

• C++标准对非函数作用域、具有静态存储期的全局对象的初始化流程有明确规定：这类对象的初始化分为零初始化、常量初始化、动态初始化三个阶段。只要对象的初始化过程无法在编译期完全完成计算（也就是不满足常量初始化的要求），就属于动态初始化范畴。
• 你定义的const LogMessage SYSTEM_STARTED(0x0001, DEBUG, "System started")，因为LogMessage的构造函数没有被声明为constexpr，哪怕构造函数体为空，也属于典型的动态初始化对象。标准明确要求这类对象的动态初始化，必须在程序跳转至main函数之前完成，不存在平台相关的偶发特性。
• 你在公开资料里很少看到这类带构造逻辑的全局const对象示例，本质原因是绝大多数示例都采用了constexpr修饰的构造函数，这类对象可以直接在编译期完成内存值填充，根本不需要在main前执行运行时构造流程，因此不会观察到构造函数的执行痕迹。

构造函数体内的自定义函数调用：语法完全允许，但存在明确的规则边界 #

• 从C++标准的语法规则层面，全局对象的构造函数体内可以调用任意自定义函数，没有任何层面的语法禁止。
• 但这类调用的安全性，完全受静态初始化顺序规则的约束：
  • 同一翻译单元（即同一个cpp文件）内定义的动态初始化全局对象，严格按照代码中的定义顺序执行构造逻辑；
  • 跨不同翻译单元定义的动态初始化全局对象，构造执行顺序是标准明确的未指定行为——这就是嵌入式开发中常见的「静态初始化顺序乱象」的根源。举个实际的场景：如果你把日志单例的定义放在LoggerSingleton.cpp，把SYSTEM_STARTED的定义放在LogMessages.cpp，编译器完全可以选择先构造LogMessages.cpp里的SYSTEM_STARTED，再构造LoggerSingleton.cpp里的单例对象，这时候构造函数里拿到的单例就是未初始化的野内存，属于标准定义的未定义行为——哪怕当前平台跑起来没有异常，只要更换链接顺序、编译器版本，就可能出现崩溃、数据错乱等问题。

嵌入式开发场景下的落地建议 #

• 你当前观察到的「全局对象构造在main前执行」的表现，恰恰说明你的嵌入式启动流程是符合C标准的：绝大多数正规的嵌入式编译器，都会把全局动态初始化的执行入口统一放在复位中断处理函数到main函数之间的启动代码段，这是C标准要求的启动流程，而非厂商私有扩展。
• 为了规避构造函数内的跨依赖调用风险，可以采用两个经过验证的通用方案：
  • 把单例的实现改成「函数内静态局部对象」模式：即在单例的getInstance方法内部定义静态局部对象，这种局部静态对象只会在第一次函数调用时完成初始化，从根本上避开跨翻译单元的初始化顺序问题；
  • 把LogMessage的构造函数声明为constexpr，实现编译期的对象内存填充，把原来构造函数里需要执行的日志注册逻辑，统一挪到main函数启动后的初始化阶段执行，彻底消除main前的跨依赖调用风险。

内容的提问来源于stack exchange，提问作者NetoBF