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

说嵌入式不能用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驱动对每个寄存器的每一位都了如指掌。但你的队友接手后看了三天才看懂你的代码。因为你的了如指掌只在你的脑子里代码里全是位运算和宏定义魔法。换成CclassUART{// 底层寄存器都在这里能看懂吗uint32_tvolatile*DRreinterpret_castuint32_t*(0x40011000);public:// 但是上层使用者不需要管这些voidsend(conststd::vectoruint8_tdata){for(autobyte:data){*DRbyte;while(!(*DR0x80));// 等待发送完成}}};底层细节还在那里完全没丢。只是通过类封装给了调用者一个干净的接口。这叫抽象不叫掩盖。你总不能说TSMC在制造芯片的时候因为不知道你写的每个晶体管是干嘛的所以芯片就不好用吧论据三“嵌入式团队没几个人会C上了C谁来维护”这个论据是最诚实的也是最有道理的。如果你们团队5个人4个只会C1个C/C混用那确实不应该用C。这不是C的问题是团队技能的问题。但我想反问一句既然你知道C有好处为什么不去学2002年的时候大部分嵌入式工程师还只会汇编。那时候有人说用C做嵌入式也被骂C太高级了掩盖了底层细节。你看历史总是惊人的相似。每个时代的技术保守派都说着同样的话只是关键词换了一下。C在嵌入式里到底适合干什么说了这么多我也不是主张所有嵌入式项目都应该用C。要分场景。适合用C的场景✅ 代码量超过5万行的嵌入式Linux应用✅ 有复杂状态机/业务逻辑的可穿戴设备固件✅ 需要图形界面LVGL/CSTML/emWin的设备✅ 网络协议栈/物联网平台✅ 需要长期维护的产品C的强类型和封装让重构更安全✅ 团队有2个以上C熟练成员不适合用C的场景❌ 裸机/RTOS上的简单外围控制点灯、读传感器❌ ROM/RAM以KB为单位的超低端MCU4KB以内的❌ 团队全员零C经验❌ 硬实时中断处理代码这部分本来也应该用C或汇编我个人的经验法则小于1万行1-5万行5-20万行大于20万行Flash 64KBFlash 256KB会C不会C项目规模C语言C语言优先C优先, C配合必须C, 否则维护成本爆炸MCU资源汇编/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*bufnewuint8_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. 模板生成代码但要关注代码膨胀// 好的模板用法——编译期计算出常量templateintNconstexprintfactorial(){static_assert(N0N10,Dont blow up the binary);returnN*factorialN-1();}// 不好的模板用法——为每个类型生成一份代码templatetypenameTTmax(T a,T b){returnab?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。不管用什么语言团队能力永远是第一位的。别跟风但也别守旧。