硬实时系统必须禁用C++异常、动态内存分配和虚函数：因栈展开不可静态分析、内存碎片破坏确定性、虚表访问引入cache miss风险；需用返回码、静态缓冲区、函数指针表替代，并通过编译选项和静态检查强制落地。
为什么硬实时系统里 throw 和 catch 必须禁用
异常机制在 C++ 中无法保证最坏执行时间（WCET）：栈展开过程依赖运行时类型信息和未定义的调用路径，编译器无法静态分析其耗时。即使你只在初始化阶段抛一次异常，链接器仍可能保留整个异常处理表（.eh_frame），增加 ROM 占用并干扰 cache 行为。
- 所有
try/catch块必须删除，包括第三方库头文件间接引入的（检查是否定义了-fno-exceptions） - 用返回码替代异常逻辑，例如将
std::vector::at()换成operator[]+ 边界预检 - 编译时强制关闭：GCC/Clang 加
-fno-exceptions，MSVC 加/EHs-；同时定义__cpp_exceptions为 0 防止头文件误判
new 和 delete 在实时任务中为何比“慢”更危险
动态内存分配的不确定性不仅在于延迟，更在于碎片化导致后续分配失败不可预测——而硬实时系统要求每次调度周期内行为完全确定。即使使用内存池，若池管理逻辑含分支或循环（如查找空闲块），WCET 仍难证明。
- 禁止所有全局/局部
new、delete、malloc、free调用；STL 容器如std::vector、std::string默认禁用（除非显式绑定静态分配器） - 替代方案：栈上数组（
int buf[256]）、静态全局缓冲区（static uint8_t rx_buffer[1024]）、或预分配的环形队列（无 malloc 的ringbuf_t结构体） - 检测手段：链接时加
--wrap=malloc --wrap=free，并在__wrap_malloc中触发编译错误或断言
虚函数调用破坏可预测性的根本原因
虚函数跳转需通过虚表（vtable）查表，而 vtable 指针存储在对象首地址，访问它本身是一次内存读取——这引入 cache miss 风险，且不同对象的 vtable 可能位于不同 cache 行，WCET 分析失效。
- 禁用
virtual关键字，移除所有纯虚类（interface抽象层改用函数指针表或模板特化） - 多态需求改用策略模式：例如通信协议处理，用
enum protocol_type+switch分发，而非BaseProtocol*指针 - 检查编译结果：对含虚函数的类，
nm -C your.o | grep vtable应为空；否则说明未彻底清理继承链
编译与静态检查必须落地的关键项
规范写在文档里没用，必须变成构建流程中的硬性门禁。很多团队只关异常但忘了 STL 内部仍可能调用 new，或以为禁用虚函数就安全，却忽略了 RTTI（dynamic_cast、typeid）隐式依赖虚表。
立即学习“C++免费学习笔记（深入）”；
- 编译选项强制组合：
-fno-exceptions -fno-rtti -fno-unwind-tables -Werror=return-type -Werror=non-virtual-dtor - 用
clang++ -Xclang -ast-dump检查关键函数 AST，确认无CXXThrowExpr、CXXNewExpr、CXXDeleteExpr、CXXDynamicCastExpr - 运行时防护：重载全局
operator new为static_assert(false, "dynamic allocation forbidden")，确保链接时报错而非静默忽略
真正难的不是禁止某项特性，而是让整个工具链（编译器、静态分析器、CI 测试脚本）把“不可预测性”当作编译错误来拦截。任何绕过这些检查的临时 patch，都会在某个 200μs 的中断响应超时里暴露出来。
