说嵌入式不能用C++的，你们写过超过10万行的嵌入式项目吗？
一句话观点：在MCU上跑C++确实是"杀鸡用牛刀"，但在超过5万行代码的嵌入式Linux应用中，不用C++才是给自己找麻烦。
先交代背景，免得被喷。
我从2008年开始做嵌入式，前7年纯C，后11年C和C++混用。做过裸机、RTOS、嵌入式Linux。用C++写过最复杂的项目是一个带图形界面的医疗诊断设备，纯C++代码12万行+驱动层C代码3万行，跑在ARM Cortex-A7上。
所以别跟我说"你没在嵌入式里写过C++"------我写了十几年了。
也别跟我说"C++不适合嵌入式"------我拿C++做的产品已经卖了上万台，通过了医疗认证，至今没出过因为C++特性导致的严重bug。
我想说：关于C++在嵌入式领域的争论，大部分观点都是建立在"没写过大型嵌入式项目"这个前提下的。
反对C++进嵌入式的三个"经典论据"，一个一个拆
论据一："C++太臃肿，不适合资源受限的环境"
这话在1985年成立，在2026年已经不成立很久了。
我们来算笔账：
一个典型的ARM Cortex-M4单片机，比如STM32F4，有192KB RAM、1MB Flash。你告诉我C++的哪个特性是这192KB跑不动的？
- 虚函数？一个vtable指针4字节，一个虚函数表就几KB。
- 模板？编译后生成的是具体代码，不会比手写的C代码更大（实际上因为编译器的优化，模板生成的代码往往比手写C更紧凑）。
- 异常？谁在嵌入式里开异常？关掉就行了。
-fno-exceptions是标准配置。 - RTTI？同上，
-fno-rtti。
真正导致C++"臃肿"名声的，是一些程序员滥用特性（比如在中断里new/malloc、深度继承链、滥用模板元编程），这是人的问题，不是语言的问题。
我最近的一个项目，C++编译出来的固件大小是208KB，而之前用C写的同功能固件是196KB。差距12KB，不到6%。 而开发时间缩短了大约30%，因为C++的vector、string、智能指针、RAII机制帮我省了大量手写内存管理的时间。
你告诉我，这6%的Flash代价值不值？
论据二："C++的抽象会掩盖底层细节，不适合做嵌入式"
这个论据我听了十几年，每次听都觉得好笑。
嵌入式工程师最引以为傲的能力之一就是"对底层了如指掌"。于是很多人形成了路径依赖："我理解的才是好的，我不理解的封装都是坏的。"
但问题来了------你对底层的"了如指掌"到底给你带来了多少实际收益？
你用C写了一个UART驱动，对每个寄存器的每一位都了如指掌。但你的队友接手后，看了三天才看懂你的代码。因为你的"了如指掌"只在你的脑子里，代码里全是位运算和宏定义魔法。
换成C++：
cpp
class UART {
// 底层寄存器都在这里，能看懂吗？
uint32_t volatile* DR = reinterpret_cast<uint32_t*>(0x40011000);
public:
// 但是上层使用者不需要管这些
void send(const std::vector<uint8_t>& data) {
for(auto byte : data) {
*DR = byte;
while(!(*DR & 0x80)); // 等待发送完成
}
}
};底层细节还在那里，完全没丢。 只是通过类封装给了调用者一个干净的接口。这叫"抽象"，不叫"掩盖"。
你总不能说TSMC在制造芯片的时候，因为不知道你写的每个晶体管是干嘛的，所以芯片就不好用吧？
论据三："嵌入式团队没几个人会C++，上了C++谁来维护？"
这个论据是最诚实的，也是最有道理的。
如果你们团队5个人，4个只会C，1个C/C++混用，那确实不应该用C++。这不是C++的问题，是团队技能的问题。
但我想反问一句：既然你知道C++有好处，为什么不去学？
2002年的时候，大部分嵌入式工程师还只会汇编。那时候有人说"用C做嵌入式"，也被骂"C太高级了，掩盖了底层细节"。
你看，历史总是惊人的相似。每个时代的技术保守派都说着同样的话，只是关键词换了一下。
C++在嵌入式里到底适合干什么？
说了这么多，我也不是主张"所有嵌入式项目都应该用C++"。要分场景。
适合用C++的场景：
- ✅ 代码量超过5万行的嵌入式Linux应用
- ✅ 有复杂状态机/业务逻辑的可穿戴设备固件
- ✅ 需要图形界面（LVGL/CSTML/emWin）的设备
- ✅ 网络协议栈/物联网平台
- ✅ 需要长期维护的产品（C++的强类型和封装让重构更安全）
- ✅ 团队有2个以上C++熟练成员
不适合用C++的场景：
- ❌ 裸机/RTOS上的简单外围控制（点灯、读传感器）
- ❌ ROM/RAM以KB为单位的超低端MCU（4KB以内的）
- ❌ 团队全员零C++经验
- ❌ 硬实时中断处理代码（这部分本来也应该用C或汇编）
我个人的经验法则：
用C++的正确姿势（别做傻事）
如果决定用C++，有些红线千万别踩：
1. 关掉你不用的特性
makefile
CXXFLAGS += -fno-exceptions -fno-rtti -fno-threadsafe-statics
CXXFLAGS += -ffunction-sections -fdata-sections
LDFLAGS += -Wl,--gc-sections关掉异常和RTTI，这两个是C++运行时开销的主要来源。在嵌入式里，你不需要它们。
2. 不在堆上分配关键资源
cpp
// 可以------在嵌入式里用new的问题不是new本身，是碎片化
auto* buf = new uint8_t[1024]; // 在初始化时一次分配
// 不要频繁new/delete
// 更好------栈分配
uint8_t buf[1024];
// 更好------静态分配
static uint8_t buf[1024];3. 用RAII管理硬件资源
这是C++对比C最大的优势：
cpp
class GpioOutput {
GPIO_TypeDef* port;
uint16_t pin;
public:
GpioOutput(GPIO_TypeDef* p, uint16_t pi) : port(p), pin(pi) {
// 构造函数里初始化
port->CR |= pin; // 配置为输出
}
~GpioOutput() {
// 析构函数里清理
port->CR &= ~pin;
port->ODR &= ~pin; // 拉低
}
void set(bool level) {
if(level) port->ODR |= pin;
else port->ODR &= ~pin;
}
};
// 使用------即使异常返回，GPIO也会被正确清理
void doSomething() {
GpioOutput led(GPIOA, GPIO_PIN_5);
led.set(true);
// 函数退出时，led的析构函数自动执行
}这不仅仅是"语法糖"。RAII让嵌入式代码的资源泄露问题从"runtime bug"变成了"compile-time guarantee"。
4. 模板生成代码，但要关注代码膨胀
cpp
// 好的模板用法------编译期计算出常量
template<int N>
constexpr int factorial() {
static_assert(N >= 0 && N <= 10, "Don't blow up the binary");
return N * factorial<N-1>();
}
// 不好的模板用法------为每个类型生成一份代码
template<typename T>
T max(T a, T b) { return a > b ? a : b; }
// 如果你给int、float、double都调用了，就会生成三份代码对于内存受限的嵌入式设备，模板要节制使用。好在现在有__attribute__((cold))和LTO来帮助压缩。
最后说一句
我对C++进嵌入式的态度一直是：别为了用C++而用C++，但也别因为"别人说不行"就不用。
我职业生涯最大的两次技术债务，都是"因为团队觉得C++太复杂，所以坚持用C"造成的------
第一次是一个LED控制器的固件，用C写到最后25000行，一个static函数调另外13个static函数，没有任何封装，任何一个人改代码，另外三个人需要rebase。
第二次是一个工业协议栈，用C写了6万行，宏定义套宏定义，void*指针满天飞。后来重构时，有C++经验的人用模板+策略模式把核心逻辑从6万行压缩到了2万行，bug率直接降了一个数量级。
语言不是银弹。但选错语言的代价，往往在项目第三年才显现出来------那时候你已经来不及换了。
所以我的建议很简单：
- 10万行以下的项目，随便你用C还是C++，都能做出来。
- 10万行以上或者需要长期维护的项目，认真考虑C++。
- 不管用什么语言，团队能力永远是第一位的。
- 别跟风，但也别守旧。