嵌入式环境下静态分配派生类数组的代码尺寸优化问题

场景背景 #

• 针对Teensy 3.2/4.1嵌入式平台，需严格控制FLASH与RAM资源占用
• 现有近70个继承自Base类的派生类，每个类需创建4个实例
• 原实现采用宏定义，但需重复编写类名，易出错；改用模板元编程重构，将实例池放入Registry类内的std::tuple数组，配合constexpr构造器初始化Wrapper数组，仅需列出一次类名即可完成所有实例创建

问题现象 #

• 当Base类添加虚函数后，类内实例池的实现会导致FLASH、RAM占用显著上升；若将实例池移至类外，资源占用则与原宏实现相当
• 类内实例池的资源占用情况，与移除constexpr修饰构造器的表现类似

原因分析 #

1. 虚函数表的重复生成 #

当实例池置于Registry类内部时，constexpr构造器触发的编译期初始化流程，可能导致编译器为每个Wrapper内的派生类实例生成独立的虚函数表副本。而将实例池移至类外时，编译器可更好地合并相同类型的虚函数表，避免重复占用FLASH空间。

2. constexpr构造器的编译期实例化限制 #

在类内部使用constexpr构造器初始化带虚函数的类实例时，编译器无法像处理全局/类外静态变量那样执行跨编译单元的优化。编译期生成的实例会被标记为不可合并，导致每个实例的虚表指针指向独立的虚表，同时实例本身的存储也无法得到复用优化，进一步增加RAM与FLASH开销。

3. std::tuple的模板实例化额外开销 #

类内的std::tuple数组在包含带虚函数的派生类实例时，模板元编程的展开过程会促使编译器为每个tuple元素生成更多辅助代码。尤其是在constexpr上下文环境中，这些辅助代码无法被有效消除，直接导致FLASH占用增加。而类外的实例池采用直接数组结构，编译器优化路径更直接，无此类额外开销。

4. 内存布局的对齐差异 #

类内实例池作为Registry类的成员，其内存布局会引入额外的对齐开销；再加上重复存储的虚表指针，最终导致RAM占用上升。类外的全局/静态实例池则能以更紧凑的方式排列，对齐开销更小。

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