3

char16_t该标准似乎对包含无法表示的字符的文字有两种不同的响应char16_t。首先，如果代码点值不能用 16 位表示（即它不在基本多语言平面 (BMP) 中），则程序格式错误（第 2.14.3/2 节）：

char16_t包含单个c-char的文字的值等于其 ISO 10646 代码点值，前提是该代码点可以用单个 16 位代码单元表示。（也就是说，只要它是一个基本的多语言平面代码点。）如果该值不能在 16 位内表示，则程序格式错误。

由于\U0001ABCD是单个c-char 1但不在 BMP 中，因此包含它的程序格式错误。

好的，但稍后在同一章中，它说如果值超出实现定义的范围，char16_t则文字具有实现定义的值（第 2.14.3/4 节）：

如果字符文字的值超出为 [...] 定义的实现定义的范围char16_t（对于以 '<code>u' 为前缀的文字）[...] ，则它的值是实现定义的

由于实现定义的范围char16_t必须至少为 16 位（以便能够存储整个 BMP），我们已经知道该程序对于超出该范围的值是非良构的。为什么标准会费心给它一个实现定义的值？

1产生规则是c-char -> universal-character-name -> \U hex-quad hex-quad

4

1 回答 1

0

根据 2.14.3/2，该程序格式错误，这意味着必须诊断错误。无需进一步分析，因为完成编译或生成可执行文件不需要实现。文字可能被认为仍然具有价值，但这并不重要。

（尽管允许实现编译和执行格式错误的程序。所以我想在这种情况下，字符文字仍然被指定为具有值的事实很重要。）

于 2012-11-25T20:09:11.087 回答