为何C++不定义部分未定义行为？不抛出错误终止的原因

1. 极致性能是C++的核心设计目标之一 #

C++从诞生起就面向系统编程、嵌入式开发、高性能计算这类对性能极度敏感的场景。如果强制给所有未定义行为（UB）场景加上运行时检查，会带来不可忽视的性能开销：

• 比如空指针解引用的检查，每一次指针访问都要插入if (p == nullptr)的判断，在循环密集型代码里会大幅拖慢执行速度；
• 整数溢出的检查，每一次算术运算后都要对比结果和容量，同样会增加指令数，降低代码执行效率。
  很多场景下，开发者能通过逻辑保证不会触发UB，这时强制检查就是完全多余的性能浪费。

2. 语言设计的"信任开发者"哲学 #

C++的设计理念是给开发者最大的控制权，相信开发者能写出安全的代码，同时允许开发者为了性能或特定需求绕过安全检查。如果把所有UB都定义成抛出错误，相当于剥夺了开发者的选择权——比如某些场景下，开发者明确知道溢出不会发生，或者甚至有意利用溢出的特性（比如某些加密算法、位运算技巧），强制检查反而会阻碍这类合理使用。

3. 静态检查的局限性 #

你提到"大部分未定义行为可被编译器捕获"，但实际上很多UB是运行时场景依赖的，编译器无法在编译期完全预判：

• 比如空指针解引用，指针的值可能来自用户输入、外部设备或者动态内存分配的结果，编译期无法确定它是否为空；
• 整数溢出的触发条件可能依赖运行时的变量值，只有在特定输入下才会发生，编译器无法提前覆盖所有可能的执行路径。
  就算编译器能做部分静态检查，也无法覆盖所有情况，强行在运行时补全检查又回到了性能问题。

4. 标准的兼容性与历史包袱 #

C继承了C语言的很多特性，而C语言本身就大量使用未定义行为来换取性能和简洁性。如果突然把这些UB都定义成明确的错误处理，会导致大量现存的C/C代码无法兼容，这是标准委员会和开发者都无法接受的。

补充：并非完全没有解决方案 #

虽然C++标准不强制运行时检查，但开发者可以通过多种方式应对UB：

• 使用编译器提供的调试选项，比如-fsanitize=undefined（GCC/Clang）或/fsanitize=undefined（MSVC），在调试阶段开启UB检查，发现潜在问题；
• 自己封装安全的工具函数，比如实现带溢出检查的整数运算、空指针安全的访问函数，在需要安全的场景下使用；
• 借助静态分析工具（比如Clang-Tidy、Cppcheck）提前发现编译期可检测的UB。

内容的提问来源于stack exchange，提问作者merovingian