主流的 MCU 开发语言为什么是 C 而不是 C++？

在单片机的地界儿里，C 语言稳坐中军帐，C++ 想分杯羹？难喽。咱电子工程师天天跟那针尖大的内存空间较劲，C++ 那些花里胡哨的玩意儿，在这儿真玩不转。

先说内存这道坎儿。您当 stm32f4 的 256k RAM、1M ROM 是标配？多数时候咱打交道的，是 stm8 这种 8k RAM 的 “小矮个儿”，stm32f1 的 32k RAM 就算是 “小康家庭” 了。就这么丁点儿地方，C 语言打个转都得缩手缩脚，C++ 带着类、对象、虚函数杀进来，光构造析构的开销就能把 ROM 啃掉一大块。您说上实时系统？C 语言写代码都得掰着字节算，C++ 的运行时环境？在这儿纯属 “奢侈品”，就像让小毛驴拉火车头，根本不配套。

再聊动态内存这事儿。keil 里 stm32f1 的 malloc 默认就 800 字节，您想用 C++ 的动态内存玩花样？那些依赖动态内存的类，分分钟把栈撑爆。单片机开发讲究的是 “把每滴血都榨干”—— 全局变量往 map 文件里一摆，编译完内存占用明明白白，出问题顺着寄存器和栈区就能摸到根儿。C++ 的动态内存监控库？得了吧，那库自己先占一块内存，本来就紧张的 RAM 哪经得起这么折腾？咱电子工程师没那么多讲究，估摸好内存直接定全局变量，爆了内存直接扒拉汇编找栈帧，比在 C++ 的内存海里捞针痛快多了。

硬件驱动这块儿，芯片厂压根没给 C++“开小灶”。就说 stm32 的 HAL 库，用句柄模仿类函数，可要是不用 cubemx 自己撸代码，那层层嵌套的函数能把人绕晕，改个驱动能薅掉半头头发。反过来看 C 语言的标准库，直接把寄存器封装得明明白白，想改哪儿就改哪儿，对着芯片手册就能硬刚寄存器位。要是发现厂商把寄存器位置改错了，分分钟就能揪出来。C++ 想玩硬件级操作？先穿过类封装的 “迷宫” 再说，等摸到寄存器，C 语言写的驱动早跑出老远了。

最后说说咱写代码的人。没错，咱在纯软大佬眼里就是 “菜”—— 四年大学就学了 C 语言和汇编，数据结构、算法啥的都是野路子，git、stackoverflow 也不熟，写的代码没少被骂 “屎山”。可您让那些玩惯高级语言的来搞单片机，分分钟在内存越界里打转。咱靠的就是对硬件的死磕劲儿，知道每一行代码在寄存器里怎么跳，C++ 的优雅在这儿不如一句精准的寄存器操作实在。您看市面上的 MCU 例程、厂商库，有几个不是 C 语言打底？生态在这儿摆着，咱犯不着为了好看去折腾那些不实用的语法糖。

在 MCU 开发这一亩三分地里，C 语言就像一把趁手的螺丝刀，简单、直接、高效，每一行代码都能钉在该钉的地方；C++ 则像一把雕花匕首，好看是好看，可在这儿施展不开。咱追求的不是代码多漂亮，而是让那几 k 的 RAM 和几十 k 的 ROM 实实在在跑起来，不出错、好调试、能落地 —— 就这点儿实在需求，C 语言足够漂亮地把活儿干完，何必去够那够不着的月亮呢？