1. 从裸机到C++：为什么要在单片机上折腾这门语言
很多人第一次接触单片机编程，都是从C语言开始的。51单片机、STM32、GD32、ESP32，这些芯片的官方例程、教学视频、开源项目，清一色都是C语言。江科大的51和32笔记在网上流传甚广，蓝桥杯单片机组也是以C语言为绝对主力。所以当有人提出“在单片机上用C++”的时候，第一反应往往是：有必要吗？资源那么紧张，C++会不会太臃肿？
我自己最早也是这个想法。直到有一次做一个带菜单系统的项目，用C语言写了一堆状态机，函数指针数组、结构体嵌套、全局变量满天飞，代码写到后面自己都理不清哪个函数改了哪个标志位。那时候我才认真去了解C++在嵌入式里的实际用法，发现事情和想象中完全不一样。
C++在单片机上的应用，核心价值不在于那些“高级特性”，而在于封装和类型安全。你完全可以在单片机上只用C++的一个子集：类、构造函数、引用、模板的简单用法、命名空间。这些特性带来的代码组织能力，是纯C很难做到的。而且现代编译器对C++的优化已经非常成熟，只要你不碰异常、不碰RTTI、不碰动态多态，生成的机器码和C几乎一样紧凑。
这篇文章适合谁看？如果你已经会用C语言点灯、写串口、调定时器，但觉得代码越写越乱，想找一个更好的组织方式，那C++在单片机上的应用就是为你准备的。如果你还在学C语言基础，建议先把指针、结构体、函数指针这三样吃透，再来看C++，会顺畅很多。
注意：这里说的C++，不是让你在单片机上跑STL容器、跑iostream、跑异常处理。那些东西在资源受限环境里是灾难。我们要用的是C++的“零开销抽象”部分。
2. 核心思路拆解：C++在单片机上到底能用什么、不能用什么
2.1 零开销抽象原则：不为没用的东西买单
C++有一个非常重要的设计哲学，叫“零开销抽象”。意思是：你用了一个高级特性，如果这个特性在运行时不需要额外开销，编译器就不会生成额外代码。比如你定义一个类，里面只有成员变量和普通成员函数，那这个类的大小和C语言的结构体完全一样，成员函数的调用也和普通函数一样，不会多一层间接。
但有些特性是有开销的，比如虚函数需要虚表指针，每个对象多一个指针的大小；异常处理需要额外的栈展开信息；RTTI需要类型信息表。这些在单片机上要慎用，尤其是RAM只有几KB的51单片机，一个虚表指针可能就占掉你十分之一的RAM。
所以我的选型原则很简单：用C++的语法糖和封装能力，不用C++的运行时机制。具体来说，类、构造函数、析构函数、引用、命名空间、模板（简单用法）、内联函数、constexpr，这些都可以放心用。虚函数在STM32级别可以酌情用，在51级别基本不考虑。异常和RTTI直接关掉。
2.2 编译器配置：怎么让C++代码不臃肿
以STM32为例，用STM32CubeIDE或者Keil MDK，都可以直接建C++工程。关键配置有几个：
- 关闭异常：
-fno-exceptions - 关闭RTTI：
-fno-rtti - 优化等级：
-Os（优化体积） - 链接时优化：
-flto
在Keil里，这些选项在Target设置里勾选。在GCC工具链里，直接加到编译参数里。实测下来，一个用C++写的GPIO封装类，和直接用寄存器操作的C代码，编译出来的二进制大小差异在几十字节以内，基本可以忽略。
提示：如果你用的是51单片机，比如STC系列，Keil C51编译器对C++的支持非常有限，基本只能当C用。所以51单片机不建议上C++，老老实实用C。C++在单片机上的主战场是ARM Cortex-M系列，比如STM32F103C8T6这种。
2.3 内存管理：不用new/delete，用静态分配
单片机上的RAM非常宝贵。STM32F103C8T6只有20KB RAM，51单片机可能只有128字节到1KB。在这种环境下，动态内存分配是禁忌。new和delete会引入堆管理代码，而且容易产生碎片。
C++的构造函数可以在静态对象上调用，不需要动态分配。你可以这样写：
class Led { public: Led(GPIO_TypeDef* port, uint16_t pin) : port_(port), pin_(pin) { // 初始化GPIO } void toggle() { HAL_GPIO_TogglePin(port_, pin_); } private: GPIO_TypeDef* port_; uint16_t pin_; }; // 静态分配，全局对象 Led led1(GPIOA, GPIO_PIN_5);这个led1对象在编译期就分配好了空间，构造函数在启动时调用，没有任何堆操作。这就是C++在单片机上最典型的用法。
2.4 和C语言的互操作：extern "C"的用法
单片机开发离不开厂商的C语言库，比如HAL库、标准外设库。C++调用C函数需要加extern "C"，否则链接时会找不到符号。通常的做法是在C头文件里加：
#ifdef __cplusplus extern "C" { #endif void HAL_GPIO_Init(...); #ifdef __cplusplus } #endif这样C和C++都能用。如果你自己写C++模块，想被C代码调用，也要在头文件里做类似处理。
3. 实操过程：从零搭建一个C++单片机工程
3.1 环境准备：VSCode + ARM GCC + OpenOCD
我平时用VSCode配C/C++环境，这套组合在Windows和Linux上都能跑。需要装的东西：
- ARM GNU Toolchain（arm-none-eabi-gcc）
- OpenOCD（用于下载和调试）
- VSCode插件：Cortex-Debug、C/C++
工程目录结构大概是这样：
project/ ├── src/ │ ├── main.cpp │ ├── led.cpp │ └── led.hpp ├── startup/ │ └── startup_stm32f103.s ├── linker/ │ └── stm32f103c8t6.ld ├── Makefile └── .vscode/ ├── launch.json └── tasks.jsonMakefile里关键编译参数：
CXXFLAGS = -mcpu=cortex-m3 -mthumb -Os -fno-exceptions -fno-rtti -fno-use-cxa-atexit -Wall LDFLAGS = -T$(LDSCRIPT) -Wl,--gc-sections -flto-fno-use-cxa-atexit这个参数很多人不知道，它是用来关掉全局对象析构注册的。单片机程序通常不会正常退出，所以不需要在退出时调用全局对象的析构函数，关掉可以省一点空间。
3.2 第一个C++类：封装一个LED
先看C语言版本：
#define LED1_PORT GPIOA #define LED1_PIN GPIO_PIN_5 void led1_init(void) { GPIO_InitTypeDef gpio = {0}; gpio.Pin = LED1_PIN; gpio.Mode = GPIO_MODE_OUTPUT_PP; gpio.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(LED1_PORT, &gpio); } void led1_on(void) { HAL_GPIO_WritePin(LED1_PORT, LED1_PIN, GPIO_PIN_RESET); } void led1_off(void) { HAL_GPIO_WritePin(LED1_PORT, LED1_PIN, GPIO_PIN_SET); } void led1_toggle(void) { HAL_GPIO_TogglePin(LED1_PORT, LED1_PIN); }这是典型的C写法，每个LED都要写一套函数，或者用宏来简化。如果有8个LED，代码会非常冗长。
C++版本：
// led.hpp #pragma once #include "stm32f1xx_hal.h" class Led { public: Led(GPIO_TypeDef* port, uint16_t pin) : port_(port), pin_(pin) { GPIO_InitTypeDef gpio = {0}; gpio.Pin = pin_; gpio.Mode = GPIO_MODE_OUTPUT_PP; gpio.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(port_, &gpio); } void on() { HAL_GPIO_WritePin(port_, pin_, GPIO_PIN_RESET); } void off() { HAL_GPIO_WritePin(port_, pin_, GPIO_PIN_SET); } void toggle() { HAL_GPIO_TogglePin(port_, pin_); } private: GPIO_TypeDef* port_; uint16_t pin_; };用的时候：
// main.cpp #include "led.hpp" Led led1(GPIOA, GPIO_PIN_5); Led led2(GPIOB, GPIO_PIN_0); int main() { while (1) { led1.toggle(); led2.toggle(); HAL_Delay(500); } }代码量少了，而且每个LED是一个独立对象，不会互相干扰。这就是封装带来的好处。
3.3 构造函数时机：全局对象什么时候初始化
C++全局对象的构造函数在main函数之前调用。在单片机启动流程里，startup_stm32f103.s里的复位处理程序会先调用SystemInit，然后调用__libc_init_array，这个函数会遍历.init_array段，调用所有全局对象的构造函数。
所以如果你在全局对象的构造函数里用了HAL库，比如HAL_GPIO_Init，需要确保HAL库已经初始化。通常HAL_Init是在main里调用的，但全局对象构造在main之前，这时候HAL还没初始化，直接调用HAL_GPIO_Init可能会出问题。
解决办法有两个：一是把外设初始化放在main里，全局对象只保存参数，不调用HAL；二是用“懒初始化”模式，第一次使用时才初始化。我一般用第一种，简单可靠。
class Led { public: Led(GPIO_TypeDef* port, uint16_t pin) : port_(port), pin_(pin), initialized_(false) {} void init() { if (!initialized_) { GPIO_InitTypeDef gpio = {0}; gpio.Pin = pin_; gpio.Mode = GPIO_MODE_OUTPUT_PP; gpio.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(port_, &gpio); initialized_ = true; } } // ... };然后在main里先HAL_Init()，再调用每个对象的init()。
3.4 中断处理：C++里怎么写中断服务函数
中断服务函数在C++里需要用extern "C"，因为中断向量表是C链接的。比如：
extern "C" void TIM2_IRQHandler(void) { if (__HAL_TIM_GET_FLAG(&htim2, TIM_FLAG_UPDATE)) { __HAL_TIM_CLEAR_FLAG(&htim2, TIM_FLAG_UPDATE); // 你的代码 } }如果你想在中断里调用C++对象的方法，要注意这个对象必须是全局的或者静态的，不能是局部的。而且中断里调用的方法最好是inline的或者简单的，避免函数调用开销。
4. 常见问题与排查技巧实录
4.1 链接错误：undefined reference to__cxa_guard_acquire
这个错误通常出现在你用了局部静态对象的时候。C++11之后，局部静态对象的初始化是线程安全的，编译器会生成__cxa_guard_acquire和__cxa_guard_release来保护初始化过程。但在单片机上，通常没有多线程，这个保护是多余的。
解决办法：加编译参数-fno-threadsafe-statics，告诉编译器不需要线程安全保护。这样就不会生成那些函数调用了。
4.2 代码体积突然变大：检查是否引入了异常和RTTI
如果你发现加了C++代码后，二进制体积突然大了几KB，大概率是异常或RTTI没关。检查编译参数里有没有-fno-exceptions和-fno-rtti。另外，dynamic_cast和typeid也会引入RTTI，尽量避免使用。
4.3 全局对象构造函数没被调用
如果你发现全局对象的构造函数没执行，检查链接脚本里.init_array段有没有被正确放置。有些自定义链接脚本可能漏掉了这个段。标准做法是在.text段后面加：
.init_array : { . = ALIGN(4); __init_array_start = .; KEEP(*(.init_array*)) __init_array_end = .; } >FLASH4.4 常见问题速查表
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 链接错误undefined reference | C++调用C函数没加extern "C" | 在C头文件加extern "C"包裹 |
| 体积突然增大 | 异常/RTTI没关 | 加-fno-exceptions -fno-rtti |
| 全局对象构造没执行 | .init_array段丢失 | 检查链接脚本 |
| 中断里调用对象方法崩溃 | 对象是局部的 | 改用全局或静态对象 |
| 局部静态对象链接错误 | 线程安全保护 | 加-fno-threadsafe-statics |
提示：如果你用的是Keil MDK，在Options for Target -> C/C++里，Misc Controls里填
--cpp11 --no_rtti --no_exceptions。不同版本参数可能略有差异，以实际为准。
5. 进阶用法：模板和constexpr在单片机上的实际价值
5.1 用模板做寄存器封装
模板在单片机上最大的价值是“编译期计算”和“类型安全”。比如你可以用模板参数来指定GPIO端口和引脚，这样编译器可以在编译期确定所有地址，生成和直接写寄存器一样的代码。
template<GPIO_TypeDef* Port, uint16_t Pin> class Gpio { public: static void init() { GPIO_InitTypeDef gpio = {0}; gpio.Pin = Pin; gpio.Mode = GPIO_MODE_OUTPUT_PP; gpio.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(Port, &gpio); } static void set() { HAL_GPIO_WritePin(Port, Pin, GPIO_PIN_SET); } static void reset() { HAL_GPIO_WritePin(Port, Pin, GPIO_PIN_RESET); } static void toggle() { HAL_GPIO_TogglePin(Port, Pin); } }; using Led1 = Gpio<GPIOA, GPIO_PIN_5>; using Led2 = Gpio<GPIOB, GPIO_PIN_0>;用的时候：
Led1::init(); Led1::toggle();这种写法没有任何运行时开销，所有参数都是编译期常量，生成的代码和直接调用HAL库一样。而且类型安全，不会把端口和引脚搞混。
5.2 constexpr做编译期计算
constexpr可以用来做编译期计算，比如计算定时器的分频值、波特率寄存器的值。这样这些计算不会占用运行时时间。
constexpr uint32_t calc_prescaler(uint32_t clk, uint32_t freq) { return clk / freq - 1; } constexpr uint32_t prescaler = calc_prescaler(72000000, 1000);这个prescaler在编译期就计算好了，直接作为常量嵌入代码。
5.3 模板的坑：代码膨胀
模板用多了会导致代码膨胀，因为每个不同的模板参数组合都会生成一份独立的代码。如果你用模板生成了几十个不同的GPIO类，每个类都有独立的init、set、reset、toggle函数，代码体积会明显增大。
解决办法：把不依赖模板参数的代码提取到基类或普通函数里。比如HAL_GPIO_Init的调用可以统一到一个非模板函数里，模板类只负责传递参数。
6. 从C到C++的迁移策略：不要一次性重写
如果你有一个现成的C语言项目，想迁移到C++，不要一次性全部重写。我的建议是：
- 先把编译器切换到C++模式，把
.c文件改成.cpp，确保能编译通过。C语言大部分代码在C++里也能编译，除了少数隐式类型转换的地方需要加显式转换。 - 然后从最乱的那个模块开始，用类重新组织。比如LED模块、按键模块、串口模块。
- 新写的代码直接用C++风格，老代码保持不动，通过
extern "C"互相调用。 - 逐步替换，每次替换一个模块，测试通过后再替换下一个。
这样风险可控，不会因为一次大改导致项目崩溃。
注意：C语言里的
malloc和free在C++里尽量不要用，用静态分配或者内存池代替。C++的new和delete在单片机上也要慎用，原因和malloc一样。
7. 我个人在实际操作中的体会
我最早在STM32F103C8T6上跑C++的时候，心里也没底，怕代码臃肿、怕出奇怪的问题。实际用下来，只要把异常和RTTI关掉，不用动态内存，代码体积和C版本几乎没差别。但代码的可读性和可维护性提升非常明显。以前一个状态机要写几百行C代码，用C++的类封装后，可能就几十行，而且逻辑清晰。
踩过的坑主要是两个：一个是全局对象构造函数在HAL初始化之前执行，导致GPIO配置失败；另一个是局部静态对象引入了线程安全保护，链接时报错。这两个问题在文章里都写了解决办法，希望对你有帮助。
最后再分享一个小技巧：如果你用VSCode写C++单片机代码，可以在.vscode/c_cpp_properties.json里配置includePath，把HAL库的头文件路径加进去，这样代码补全和跳转都会很顺畅。另外，compileCommands指向compile_commands.json，可以让VSCode准确理解你的编译参数，避免误报错误。
