当前位置：首页 > news >正文

说嵌入式不能用C++的，你们写过超过10万行的嵌入式项目吗？

news 2026/7/17 23:48:06

说嵌入式不能用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++：

classUART{// 底层寄存器都在这里，能看懂吗？uint32_tvolatile*DR=reinterpret_cast<uint32_t*>(0x40011000);public:// 但是上层使用者不需要管这些voidsend(conststd::vector<uint8_t>&data){for(autobyte: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. 关掉你不用的特性

CXXFLAGS += -fno-exceptions -fno-rtti -fno-threadsafe-statics CXXFLAGS += -ffunction-sections -fdata-sections LDFLAGS += -Wl,--gc-sections

关掉异常和RTTI，这两个是C++运行时开销的主要来源。在嵌入式里，你不需要它们。

2. 不在堆上分配关键资源

// 可以——在嵌入式里用new的问题不是new本身，是碎片化auto*buf=newuint8_t[1024];// 在初始化时一次分配// 不要频繁new/delete// 更好——栈分配uint8_tbuf[1024];// 更好——静态分配staticuint8_tbuf[1024];

3. 用RAII管理硬件资源

这是C++对比C最大的优势：

classGpioOutput{GPIO_TypeDef*port;uint16_tpin;public:GpioOutput(GPIO_TypeDef*p,uint16_tpi):port(p),pin(pi){// 构造函数里初始化port->CR|=pin;// 配置为输出}~GpioOutput(){// 析构函数里清理port->CR&=~pin;port->ODR&=~pin;// 拉低}voidset(boollevel){if(level)port->ODR|=pin;elseport->ODR&=~pin;}};// 使用——即使异常返回，GPIO也会被正确清理voiddoSomething(){GpioOutputled(GPIOA,GPIO_PIN_5);led.set(true);// 函数退出时，led的析构函数自动执行}

这不仅仅是"语法糖"。RAII让嵌入式代码的资源泄露问题从"runtime bug"变成了"compile-time guarantee"。

4. 模板生成代码，但要关注代码膨胀

// 好的模板用法——编译期计算出常量template<intN>constexprintfactorial(){static_assert(N>=0&&N<=10,"Don't blow up the binary");returnN*factorial<N-1>();}// 不好的模板用法——为每个类型生成一份代码template<typenameT>Tmax(T a,T b){returna>b?a:b;}// 如果你给int、float、double都调用了，就会生成三份代码