第三章 面向对象编程核心：类、对象、封装、继承、多态与C语言嵌入式差异

嵌入式开发长期由C语言主导，但随着MCU算力提升、代码规模膨胀以及复杂状态机与协议栈的普及，C++在嵌入式领域的应用比例逐年上升。本章的核心目标不是泛泛讲解C++语法，而是聚焦于嵌入式场景下如何正确运用类、对象、封装、继承与多态，并深入剖析C语言与C++在底层实现上的本质差异。你将看到：一个类在内存中如何布局、虚函数调用究竟消耗多少时钟周期、以及为什么在中断服务函数中不适合调用虚函数。这些知识将直接决定你能否写出既高效又可维护的嵌入式C++代码。

3.1 核心原理：从C语言结构体到C++类的演进

在嵌入式C语言开发中，我们习惯使用结构体（struct）来组织数据，再编写独立的函数来操作这些数据。例如，管理一个I2C传感器设备时，通常会定义结构体保存设备地址、寄存器映射和状态标志，然后编写 Sensor_Init()、Sensor_Read() 等函数，并将结构体指针作为第一个参数传入。这种方式的本质是数据与操作分离，虽然灵活，但随着项目规模扩大，会出现函数命名冲突、模块间耦合度高、难以复用等问题。

C++的类（class）将数据成员和成员函数封装在一个单元内，默认情况下成员是私有的（private），只有通过公有（public）接口才能访问。这种封装机制带来了三个直接好处：第一，外部代码无法直接修改内部状态，必须通过接口函数，从而保证数据完整性；第二，接口与实现分离，修改内部实现不影响外部调用；第三，命名空间隔离，不同类的同名函数互不干扰。

从底层看，C++对象在内存中的布局与C语言结构体非常相似。一个不包含虚函数的类对象，其内存布局就是成员变量的顺序排列，与struct完全一致。这意味着C++对象可以安全地与C语言结构体互相转换，这在嵌入式混合编程中极为重要。例如，你可以将C++类对象通过 reinterpret_cast 转换为C结构体指针，传递给C语言编写的驱动库。

3.2 判断方法：何时选择C++而非C

并非所有嵌入式项目都适合引入C++。根据实践经验，以下场景适合采用C++：代码量超过2万行、存在多个相似设备驱动需要复用、状态机逻辑复杂、需要实现回调机制或事件驱动架构。相反，以下场景应坚持使用C：资源极度受限（Flash小于32KB）、对实时性要求极端苛刻（中断延迟必须控制在微秒级）、团队C++经验不足。

一个实用的判断标准是“虚函数代价评估”。虚函数通过虚函数表（vtable）实现动态绑定，每次调用需要两次间接寻址：先从对象中取出vptr指针，再通过vptr找到实际函数地址。在ARM Cortex-M4上，这大约增加3-5个时钟周期。如果某个函数在1kHz中断中每秒调用1000次，额外开销仅为3-5微秒，完全可以接受。但如果是在10kHz的ADC采样循环中调用，就需要谨慎评估。

3.3 案例拆解：用C++重写多传感器管理模块

假设我们正在开发一款环境监测节点，需要同时管理温度传感器（SHT30）、湿度传感器（SHT30）和气压传感器（BMP280）。在C语言方案中，我们通常为每个传感器编写独立的驱动函数，然后在上层通过switch-case分发。这种方式的痛点在于：新增传感器类型时，需要修改分发逻辑；不同传感器的初始化参数和读取流程差异较大，代码重复度高。

采用C++后，我们设计一个抽象基类 ISensor，定义纯虚函数 Init()、Read() 和 GetID()。每个具体传感器继承该基类并实现各自逻辑。上层代码只需持有 ISensor* 指针数组，通过统一接口操作所有传感器。这样新增传感器时，只需添加一个新类，无需修改上层逻辑。

class ISensor {
public:
    virtual bool Init() = 0;
    virtual bool Read(uint8_t* buf, uint8_t len) = 0;
    virtual uint8_t GetID() = 0;
    virtual ~ISensor() {}
};

class SHT30 : public ISensor {
private:
    uint8_t i2c_addr;
    uint8_t id;
public:
    SHT30(uint8_t addr, uint8_t id) : i2c_addr(addr), id(id) {}
    bool Init() override { /* I2C初始化序列 */ }
    bool Read(uint8_t* buf, uint8_t len) override { /* 读取温湿度 */ }
    uint8_t GetID() override { return id; }
};

class BMP280 : public ISensor {
private:
    uint8_t i2c_addr;
    uint8_t id;
public:
    BMP280(uint8_t addr, uint8_t id) : i2c_addr(addr), id(id) {}
    bool Init() override { /* 配置BMP280寄存器 */ }
    bool Read(uint8_t* buf, uint8_t len) override { /* 读取气压 */ }
    uint8_t GetID() override { return id; }
};

// 上层管理
ISensor* sensors[3];
sensors[0] = new SHT30(0x44, 1);
sensors[1] = new SHT30(0x45, 2);
sensors[2] = new BMP280(0x76, 3);
for (int i = 0; i < 3; i++) {
    sensors[i]->Init();
    uint8_t data[6];
    sensors[i]->Read(data, 6);
}

这个案例中，我们使用了继承和多态。每个传感器对象在内存中除了自身数据成员外，还包含一个隐藏的vptr指针，指向各自的虚函数表。SHT30和BMP280的虚函数表内容不同，因此调用 Read() 时会自动路由到正确的实现。在Cortex-M4上，每个传感器对象额外占用4字节（vptr），三个对象共12字节，代价极小。

需要注意，上述代码使用了 new 动态分配内存。在嵌入式环境中，除非使用内存池或静态分配，否则应避免动态 new。更稳妥的做法是使用静态对象：

SHT30 sht30_1(0x44, 1);
SHT30 sht30_2(0x45, 2);
BMP280 bmp280(0x76, 3);
ISensor* sensors[3] = {&sht30_1, &sht30_2, &bmp280};

这样所有对象都在全局数据段静态分配，不涉及堆操作，避免了内存碎片和分配失败的风险。

3.4 常见误区与总结复盘

误区一：在中断服务函数（ISR）中调用虚函数。 虚函数调用依赖vptr和vtable，如果ISR执行期间主程序正在修改对象（例如重新初始化），可能导致vptr被破坏，引发不可预料的跳转。此外，虚函数调用可能触发编译器生成额外的栈操作，增加中断延迟。正确做法是：ISR中只设置标志位，主循环中处理实际逻辑。

误区二：过度使用继承层次。 嵌入式代码追求扁平化，过深的继承链（超过3层）会导致代码难以理解和调试。建议优先使用组合而非继承。例如，一个传感器模块包含I2C通信对象和数据处理对象，而不是让传感器类继承I2C类。

误区三：忽略构造和析构函数的执行时机。 在C++中，全局对象的构造函数在 main() 之前执行，析构函数在 main() 之后执行。如果构造函数中访问了尚未初始化的硬件外设（如UART），会导致系统崩溃。解决方案是使用“惰性初始化”模式，即在首次使用时才初始化硬件。

误区四：盲目启用异常和RTTI。 嵌入式编译器通常使用 -fno-exceptions 和 -fno-rtti 选项来减小代码体积。异常处理需要额外的栈展开机制，RTTI（运行时类型识别）需要为每个类生成类型信息，两者都会显著增加Flash占用。在资源受限的MCU上，应使用错误码返回代替异常。

总结复盘： 面向对象编程为嵌入式开发带来了更好的代码组织性和可维护性，但必须付出一定的资源代价。核心原则是：用封装保护数据，用继承复用代码，用多态实现扩展，但始终以资源消耗为衡量标准。 在实际项目中，建议先评估目标MCU的Flash和RAM余量，再决定是否引入虚函数。对于性能关键路径（如ADC中断、PID控制循环），使用普通成员函数或C风格函数；对于业务逻辑层（如协议解析、设备管理），可以放心使用多态。

最后，记住C++与C的互操作性。在混合编程时，使用 extern "C" 包裹C语言头文件，避免C++名称修饰导致链接失败。同时，保持C++对象的POD（Plain Old Data）特性，使其可以安全地通过DMA或memcpy操作，这在处理通信缓冲区时尤为重要。