__libc_init_array与全局对象构造顺序问题咨询

1. 能不能强制__libc_init_array的构造顺序？ #

可以，但这是编译器/链接器专属的黑科技，完全不具备可移植性：

• 在ARM GCC/GCC环境下，你可以给全局对象加__attribute__((init_priority(N)))属性，N的取值范围一般是101到65535（不同平台可能有细微差别），数值越小，构造越早。比如：

  A globalA __attribute__((init_priority(101)));
  B globalB __attribute__((init_priority(102))); // 保证B在A之后构造
  

• 但要注意：这是编译器扩展，换Keil、IAR这类工具链可能语法不一样，甚至直接不支持。而且同一优先级的对象构造顺序还是未定义的。

2. 依赖__libc_init_array的构造顺序是不是错误？ #

__libc_init_array本身是编译器实现全局对象构造的正常入口，但依赖它的构造顺序绝对是错误实践。C++标准明明白白规定：不同编译单元里的全局对象，构造顺序是未定义的；只有同一编译单元内的对象，才会按声明顺序构造。你依赖__libc_init_array的顺序，本质就是依赖未定义行为，出问题是迟早的事。

3. 构造函数里用依赖的全局成员是不是不良实践？ #

必须是。构造函数的本职工作是初始化当前对象自己的成员，要是在构造阶段依赖其他全局对象的状态，而对方的构造顺序又没法保证，那必然会踩未定义行为的坑——就像你遇到的硬fault。哪怕现在同一编译单元里顺序对了，以后代码重构挪个位置，隐患立马就炸。

4. 比new和临时initialize函数更好的方案 #

方案1：懒汉式单例（单片机可简化） #

把依赖的全局对象改成懒汉单例，第一次用的时候才初始化，从根源上保证依赖对象先就绪：

class A {
public:
    static A& getInstance() {
        static A instance; // C++11之后静态局部变量的初始化是线程安全的，单片机没多线程的话完全不用操心
        return instance;
    }
};

class B {
public:
    B() {
        // 这里调用A的单例，此时A已经完成初始化
        A& a = A::getInstance();
        // 正常操作a就行
    }
};

B globalB; // 现在B构造时会触发A的初始化，顺序完全可控

这个方案不用大改现有代码，只要把依赖的全局对象改成单例就行，重构量比全换成new小太多。

方案2：把有依赖的全局对象集中到同一个编译单元 #

C++标准保证同一编译单元里的全局对象按声明顺序构造，所以你可以把A、B这类有依赖的全局对象都放到同一个.cpp文件里，按依赖顺序声明：

// global_deps.cpp
#include "A.h"
#include "B.h"

A globalA; // 先声明，先构造
B globalB; // 后声明，后构造，此时A已经初始化好了

要是原来的全局对象分散在多个文件，就把它们移到这个专门的文件里，按依赖排序就行，操作简单，效果可靠。

方案3：用C++20的constinit（看编译器支持） #

如果你的单片机工具链支持C++20，可以用constinit关键字让全局对象在编译期初始化，此时同一编译单元内的顺序是严格按声明来的：

constinit A globalA;
constinit B globalB; // 同一编译单元内，A先构造

不过要注意，跨编译单元的顺序还是没保证，而且很多老的单片机编译器可能还不支持C++20，得先确认工具链版本。

最后说一句：优先选方案1或方案2，这俩重构量小，还能彻底解决顺序问题，比临时加initialize函数靠谱多了。尽量别碰init_priority，除非你这辈子都不换编译器。

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