构造函数优化：初始化列表 vs 成员赋值

在嵌入式 C++ 项目中，我们很容易把精力放在“看得见”的地方：中断、DMA、时序、缓存命中率、Flash/RAM 占用……而对于构造函数这种“看起来只执行一次”的代码，往往下意识地放松了警惕。

但实际上，在对象创建频繁、内存紧张、构造路径复杂的系统中，构造函数的写法，直接影响：

• 是否产生多余的构造 / 析构
• 是否引入隐藏的默认初始化成本
• 是否破坏对象的不变量
• 是否在编译期就已经“输掉了优化空间”

而这些问题，几乎都集中体现在一个地方：你是否使用了初始化列表。

一、一个常见、但并不“无害”的写法

很多人最早接触 C++ 时，构造函数往往是这样写的：

classTimer{public:Timer(uint32_tperiod){period_=period;enabled_=false;}private:uint32_tperiod_;boolenabled_;};

乍一看没有任何问题，逻辑清晰、可读性也不错。

但在编译器眼中，这段代码的真实含义是：

1. period_被默认初始化
2. enabled_被默认初始化
3. 进入构造函数体
4. 对两个成员执行赋值操作

也就是说，成员至少被“处理”了两次。

在桌面平台上，这种开销通常可以忽略；但在嵌入式系统里，尤其是：

• 构造对象数量多
• 成员是结构体 / 数组 / STL 容器
• 构造发生在启动阶段（Boot / Driver Init）

这个“看不见的默认初始化”就开始变得真实存在了。

二、初始化列表并不是“语法糖”

对比一下使用初始化列表的写法：

classTimer{public:Timer(uint32_tperiod):period_(period),enabled_(false){}private:uint32_tperiod_;boolenabled_;};

这里的关键变化并不是“少写了几行代码”，而是对象生命周期发生了变化。这里我们的成员初始化变得更加直接——直接在构造阶段完成初始化，换句话说，初始化列表不是赋值，它是构造的一部分。

三、某些成员，根本“不能被赋值”

在嵌入式系统中，这种情况并不少见。

1.const成员

classDevice{public:Device(uint32_tid):id_(id){}private:constuint32_tid_;};

const成员只能在初始化阶段赋值一次，构造函数体内的赋值在语义上是非法的。这不是语法限制，而是语言层面对“对象不变量”的保护。

2. 引用成员

classDriver{public:Driver(GPIO&gpio):gpio_(gpio){}private:GPIO&gpio_;};

引用一旦绑定，就不能再指向其他对象。因此，初始化列表是唯一正确的写法。

3. 没有默认构造函数的成员

在你自己的框架代码中，这种类型其实非常常见：

classSpiBus{public:explicitSpiBus(uint32_tbase_addr);};

如果一个类作为成员存在：

classSensor{public:Sensor():spi_(SPI1_BASE){}private:SpiBus spi_;};

此时如果不用初始化列表，代码甚至无法通过编译。

四、初始化列表带来的“语义完整性”

在嵌入式工程里，我们经常强调“对象在构造完成后，必须处于可用状态”。初始化列表天然符合这一原则。

classRingBuffer{public:RingBuffer(uint8_t*buf,size_t size):buffer_(buf),size_(size),head_(0),tail_(0){}private:uint8_t*buffer_;size_t size_;size_t head_;size_t tail_;};

这种写法传达的信息非常明确：

对象一旦构造完成，内部状态就是完整、自洽的。

而如果把初始化拆散在构造函数体中，实际上就允许了“半初始化状态”的存在，这在底层系统中是非常危险的设计信号。

五、编译器优化视角：初始化列表 = 更大的优化空间

从编译器的角度看：

• 初始化列表提供了确定的构造语义
• 成员的初始值在构造阶段已知
• 更容易进行：
  • 常量传播
  • 构造消除
  • 栈上对象合并
  • 甚至在某些场景下完全消除对象

尤其是在你大量使用constexpr、inline、模板时，初始化列表是编译期优化的前提条件之一。

最后

初始化列表并不是什么“高级技巧”，其实并不复杂，对于嵌入式系统中，每一次多余的初始化，都会真实地变成指令、变成 Flash、变成时间。而初始化列表，正是那种不写就亏、写了稳赚的现代 C++ 基本功。