C++中错误值何时不符合对象类型的有效值要求？

一、问题的核心矛盾 #

根据C++标准[conv.lval] p3.4条款：

否则，读取泛左值指示的对象（[defns.access]），对象中包含的值即为纯右值结果。若结果为错误值（[basic.indet]）且其值表示中的位不符合对象类型的有效值要求，则行为未定义。

比如这段代码：

bool x;      // C++26起，x拥有错误值
bool y = x;  // 触发左值到右值转换

这里的疑问在于：既然错误值属于定义良好的行为范畴，编译器为何不能始终为未初始化对象选择符合类型有效值要求的错误值？如果此时行为可能陷入未定义，似乎违背了错误行为的设计初衷。

二、运行时开销是核心限制 #

P2795R5《未初始化读取的错误行为》中明确提到：

该行为变更会给现有代码带来运行时开销，因为通常现在需要额外的内存初始化操作。

标准条款[basic.indet] p1.2规定：

否则，字节拥有错误值，每个值由实现独立于程序状态确定。

这里的“由实现确定”并非强制要求编译器必须初始化内存为有效值，而是给了实现选择权：编译器可以选择初始化（比如清零，让bool得到合法的0值），但也可以选择不做额外初始化——毕竟额外的初始化操作会增加运行时开销，对于追求性能的场景，实现更倾向于跳过这一步。

三、何时会触发“错误值不符合有效值要求”的情况 #

这种情况通常发生在实现选择跳过初始化时：

• 未初始化的内存会保留之前程序运行或硬件遗留的垃圾位模式，这些位模式可能刚好落在当前对象类型的有效值范围之外。比如bool类型的有效值通常是0和1，但如果实现用1字节存储bool，未初始化的内存可能出现0x02这样的位模式，这就不符合bool的有效值要求。
• 部分硬件平台的内存单元在未初始化时会产出特殊的位组合，这些组合无法被解释为目标类型的合法值，此时读取就会触发未定义行为。

四、错误行为的设计初衷与现实妥协 #

错误行为的定义是实现建议诊断的定义良好行为，其初衷是让未初始化读取的行为从“未定义”转向“定义良好但需诊断”，但标准同时兼顾了性能需求：

• 允许实现选择初始化错误值为有效值（避免UB），但不强制要求——因为强制初始化会给所有代码带来额外开销，这对性能敏感的场景是不可接受的。
• 当实现选择不初始化时，就可能出现错误值不符合有效值要求的情况，此时行为退化为未定义，这是性能与安全性之间的妥协。

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