📚 课程目录第2章 C++基础回顾与嵌入式特性

2、C++基础回顾与嵌入式特性：面向对象核心（类、继承、多态）、内存管理基础、const/static/引用、嵌入式C++编码规范

嵌入式系统开发长期以C语言为主，但随着MCU算力提升、代码规模膨胀以及复杂状态机与协议栈的普及，C++在嵌入式领域的应用比例逐年上升。C++并非“更复杂的C”，而是引入了抽象封装、资源生命周期管理、编译期约束三大能力。本章聚焦嵌入式开发者最常用的C++子集：类与对象、继承与多态、内存管理、const/static/引用，以及嵌入式环境下的编码规范。我们强调“面向硬件约束的C++”，即所有语法特性都必须考虑ROM/RAM占用、实时性、异常安全与可移植性。

2.1 面向对象核心：类、继承、多态

核心原理

嵌入式C++的面向对象并非为了“炫技”，而是为了模块化硬件驱动、封装外设寄存器操作、复用协议栈代码。类将数据（成员变量）与操作（成员函数）绑定，形成内聚单元。继承用于表达“is-a”关系，例如 class UART_Device : public SerialDevice。多态则通过虚函数实现运行时行为分派，其底层依赖虚函数表（vtable）——每个含虚函数的类都有一个隐藏的指针（vptr）指向该表。在Cortex-M等MCU上，vptr占用4字节（ARMv7-M）或8字节（ARMv8-M），且每次虚函数调用多一次间接跳转，需评估实时性影响。

判断方法或操作流程

何时使用虚函数：当驱动层需要支持多种硬件变体（如不同型号的传感器）且编译期无法确定具体类型时，使用虚函数；若硬件型号在编译期已知，优先使用模板或if constexpr。
继承深度控制：嵌入式项目继承层次建议不超过3层，过深会导致代码难以调试且增加ROM占用。
虚函数表位置：vtable通常存放在只读数据区（.rodata），不占用RAM，但vptr存在于每个对象实例中。

特性	普通成员函数	虚函数	纯虚函数
调用方式	编译期绑定	运行时绑定（vtable）	运行时绑定
ROM开销	函数代码	函数代码 + vtable	函数代码 + vtable
RAM开销	无额外	每个对象 +4/8字节（vptr）	每个对象 +4/8字节
典型用途	工具函数、内部逻辑	驱动接口、回调	抽象基类、接口定义

案例拆解：传感器驱动抽象

假设项目需要支持SHT30和HDC1080两款温湿度传感器，二者I2C寄存器地址和转换公式不同。设计抽象基类：

class TempHumiditySensor {
public:
    virtual bool init() = 0;
    virtual bool read(float& temp, float& hum) = 0;
    virtual ~TempHumiditySensor() {}
};

class SHT30 : public TempHumiditySensor {
public:
    bool init() override { /* 配置I2C、发送初始化命令 */ }
    bool read(float& temp, float& hum) override { /* SHT30专用读取 */ }
};

class HDC1080 : public TempHumiditySensor {
public:
    bool init() override { /* HDC1080初始化 */ }
    bool read(float& temp, float& hum) override { /* HDC1080读取 */ }
};

业务层只需持有TempHumiditySensor*指针，通过工厂函数根据硬件配置创建具体对象。这样新增传感器型号时无需修改业务代码，符合开闭原则。但需注意：每个对象多4字节vptr，若系统同时管理50个传感器，额外消耗200字节RAM，在资源紧张的MCU上需权衡。

风险提醒：在中断服务函数（ISR）中调用虚函数可能导致非确定性延迟，因为vtable查找和间接跳转增加了执行时间。ISR中应避免使用虚函数，改用直接函数调用或函数指针表。

2.2 内存管理基础

核心原理

嵌入式C++内存分为四个区域：栈（Stack）、堆（Heap）、静态存储区（.data/.bss）、代码区（.text）。栈由编译器自动管理，大小通常在1KB~64KB（取决于MCU和链接脚本）；堆由程序员通过new/delete或malloc/free管理；静态区存放全局变量和static变量。嵌入式环境最忌讳堆的频繁分配与释放，因为会产生碎片且分配时间不确定。

操作流程与判断方法

优先使用栈：局部对象、小型临时缓冲区（<256字节）应使用栈分配，速度快且无碎片。
静态分配优先于动态：通信缓冲区、协议解析状态机等生命周期固定的对象，使用全局或static数组。
若必须使用堆：在初始化阶段一次性分配，运行期间不释放；或使用内存池（Memory Pool）固定大小块分配。
禁止在ISR中new/delete：堆操作非线程安全且可能阻塞。

分配方式	速度	碎片风险	确定性	适用场景
栈	纳秒级	无	完全确定	局部变量、小数组
静态区	编译期	无	完全确定	全局缓冲区、常量表
堆（malloc）	微秒级	高	不确定	不推荐在MCU使用
内存池	百纳秒级	低（固定块）	较确定	网络帧、DMA缓冲区

案例拆解：内存池实现

某CAN网关需要处理不同长度的CAN FD报文，最大64字节。为避免堆碎片，设计固定块内存池：

class FixedMemoryPool {
    static constexpr uint32_t BLOCK_SIZE = 64;
    static constexpr uint32_t BLOCK_COUNT = 16;
    uint8_t pool[BLOCK_SIZE * BLOCK_COUNT];
    bool used[BLOCK_COUNT];
public:
    void* allocate() {
        for (uint32_t i = 0; i < BLOCK_COUNT; i++) {
            if (!used[i]) { used[i] = true; return &pool[i * BLOCK_SIZE]; }
        }
        return nullptr; // 池耗尽
    }
    void deallocate(void* p) {
        uint32_t idx = ((uint8_t*)p - pool) / BLOCK_SIZE;
        used[idx] = false;
    }
};

该池分配时间固定为遍历16个标志位，最坏情况微秒级，且无外部碎片。代价是内部碎片（若实际数据仅20字节，仍占用64字节块）。在内存充足时，这是嵌入式C++管理动态对象的推荐方案。

经验：在C++中重写全局new和delete操作符，将其路由到内存池，可让标准容器（如std::vector）也使用池化内存，但需谨慎处理对齐和并发。

2.3 const/static/引用

核心原理

这三个关键字在嵌入式C++中承担重要的编译期约束和存储优化职责。const声明不可修改的变量或成员函数，帮助编译器优化并防止误操作；static在类中表示静态成员（属于类而非对象），在函数内表示局部静态变量（生命周期延长至程序结束）；引用是变量的别名，底层实现为指针，但语法上更安全，且不能为空。

判断方法或操作流程

const成员函数：不修改成员变量的函数应标记为const，例如uint8_t getStatus() const。这允许const对象调用该函数，且编译器可进行更多优化。
static成员变量：在类内声明，类外定义。用于所有对象共享的计数器、硬件寄存器基地址等。
引用参数：传递大型结构体（如寄存器配置结构体）时，使用const T&避免拷贝，同时保证不修改原数据。
constexpr：嵌入式开发中，能用constexpr代替#define定义常量，获得类型检查和编译期计算。

关键字	作用域	生命周期	存储位置	典型嵌入式用途
const	块/类/文件	编译期	.rodata（若初始化）	查表、硬件参数
static（局部）	函数内	程序运行期	.data/.bss	状态机计数器
static（类成员）	类	程序运行期	.data/.bss	共享资源锁、实例计数
引用	块/参数	与绑定变量相同	无独立存储（编译器优化）	函数参数传递

案例拆解：寄存器映射与constexpr

以STM32的GPIO为例，使用constexpr定义寄存器地址和位掩码，避免魔法数字：

class GPIO {
    static constexpr uint32_t BASE_ADDR = 0x40020000;
    static constexpr uint32_t MODER_OFFSET = 0x00;
    static constexpr uint32_t ODR_OFFSET = 0x14;
    static constexpr uint32_t PIN5_MODE_MASK = 0x3 << 10;
    
    volatile uint32_t* const moder;
    volatile uint32_t* const odr;
public:
    GPIO() : moder(reinterpret_cast<volatile uint32_t*>(BASE_ADDR + MODER_OFFSET)),
             odr(reinterpret_cast<volatile uint32_t*>(BASE_ADDR + ODR_OFFSET)) {}
    
    void setPin5Output() {
        *moder = (*moder & ~PIN5_MODE_MASK) | (0x1 << 10);
    }
    void writePin5(bool high) {
        if (high) *odr |= (1 << 5);
        else *odr &= ~(1 << 5);
    }
};

这里constexpr确保地址在编译期计算，volatile防止编译器优化寄存器读写，引用成员moder和odr在构造函数中初始化，保证非空且不可重新绑定。static constexpr成员不占用对象空间，所有GPIO实例共享同一份常量。

常见误区：在嵌入式C++中，const成员函数并不保证硬件寄存器不被修改——如果成员变量是指向寄存器的指针，const只保证指针本身不变，指向的内容仍可修改。正确做法是将指针声明为volatile uint32_t* const。

2.4 嵌入式C++编码规范

核心原理

嵌入式C++编码规范的核心目标是可预测性、可维护性、可移植性。由于MCU资源有限且对可靠性要求极高，规范通常比桌面C++更严格。主流参考为MISRA-C++:2008和AUTOSAR C++14指南。关键约束包括：禁止异常（避免运行时开销和不确定行为）、禁止RTTI（typeid和dynamic_cast）、限制多重继承、禁止new的隐式调用等。

操作流程与判断方法

禁止异常：使用错误码或返回bool表示失败。异常处理在Cortex-M上需要额外的栈空间和运行时支持，且破坏实时性。
禁止RTTI：不使用dynamic_cast和typeid，改用基类虚函数或显式类型标志。
限制堆使用：默认禁止new/delete，除非项目有内存池方案。
命名规范：类名使用PascalCase，函数/变量使用camelCase，宏使用UPPER_CASE，成员变量加m_前缀。
头文件规范：使用#pragma once或include guard，禁止在头文件中定义非inline函数。

规范项	推荐做法	禁止做法	原因
异常	返回错误码	throw/catch	运行时开销、非确定性
RTTI	虚函数分派	dynamic_cast	ROM占用、性能损失
多重继承	接口继承（纯虚类）	多实现继承	歧义、复杂性
操作符重载	仅重载与语义相关的	滥用<<、++等	可读性下降
模板	谨慎使用，控制实例化数量	深度模板元编程	代码膨胀、编译时间

案例拆解：规范落地实践

某车载ECU项目采用C++开发，团队制定以下落地规则：

所有类必须显式声明virtual析构函数（若有多态），否则禁止继承。
全局对象禁止使用动态初始化（即构造函数中不能依赖其他全局对象），避免静态初始化顺序问题。
中断回调函数必须为普通C函数或static成员函数，不能是虚函数。
每个.cpp文件包含自检函数void selfTest()，在启动时调用，验证关键数据结构。

通过代码审查工具（如PC-lint、Cppcheck）配合MISRA规则集，在CI流水线中自动检查。实际效果：新入职工程师代码缺陷率降低40%，且因禁止异常和RTTI，固件ROM占用比使用完整C++特性减少约15%。

总结复盘：嵌入式C++不是“C + class”，而是面向对象思想与硬件约束的平衡艺术。核心要点：①多态用虚函数但控制深度；②内存分配以栈和静态区为主，堆必须池化；③const/static/引用是编译期安全和优化的利器；④编码规范以MISRA为基线，结合项目实际裁剪。掌握这些，即可在保持C语言高效性的同时获得C++的抽象能力。