字符文字的类型由以下规则指定：
不以u8，u，U或L开头的字符文字是普通字符文字。包含单个可在执行字符集中表示的c-char的普通字符文字，其类型为char，其值等于执行字符集中c-char的编码的数值。包含多个c字符的普通字符文字是多字符文字。多字符文字或包含在执行字符集中无法表示的单个c-char的普通字符文字受条件支持，类型为int，并且具有实现定义的值。
因此，请考虑以下示例
#include <iostream>
int main(){
auto c = '\u0080';
std::cout<< typeid(c).name();
}
的类型c是int（由GCC报告）。为什么类型cIS int？
根据c-char的语法，其定义为：
字符：
- 源字符集的任何成员，单引号'，反斜杠或换行符除外
- 转义序列
- 通用字符名称
在此示例中，\u0080是一个通用字符名称，它是单个c字符。因此，普通字符文字'\u0080'不包含多个c-char。GCC的默认执行字符集为UTF-8。这意味着，\u0080可以完全由UTF-8集表示。为什么GCC指定的类型c是int？尽管我知道这样的代码点值不能用char对象表示，但这不是以上规则指出的内容。是GCC错误还是我误会的东西？如何解释“在执行字符集中可表示”？
GCC的默认执行字符集为UTF-8。
问题就在这里。即，这是不正确的。或者至少不是以C ++标准的含义。
该标准将“基本字符集”定义为96个不同字符的集合。但是，它没有为它们定义编码。即，字符“ A”是“基本字符集”的一部分。但是未指定该字符的值。
当标准定义“基本执行字符集”时，它将在基本集中添加一些字符，但同时也定义了从字符到值的映射。但是，在NUL字符之外为0（并且必须以连续的顺序对数字进行编码），它可以使实现自己确定映射是什么。
这就是问题所在：根据该术语的任何合理定义，UTF-8并不是“字符集”。
Unicode是一个字符集。它定义了一系列存在的字符及其含义。它还将Unicode字符中的每个字符设置一个唯一的数字值（一个Unicode代码点）。
UTF-8不是。UTF-8是一种用于编码字符的方案，通常在Unicode字符集中（尽管它并不挑剔；它可以适用于任何21位数字，并且可以扩展为32位）。
因此，当GCC的文档说：
[执行字符集]由用户控制；默认值为UTF-8，与源字符集匹配。
该语句没有意义，因为如前所述，UTF-8是文本编码，而不是字符集。
GCC的文档（可能还有GCC的命令行选项）似乎发生了什么，就是他们将“执行字符集”和“窄字符编码方案”的概念混为一谈。默认情况下，UTC-8是GCC编码窄字符串的方式。但这与说它的“执行字符集”不同。
也就是说，您可以使用UTF-8来仅编码C ++定义的基本执行字符集。使用UTF-8作为窄字符编码方案与执行字符集无关。
请注意，Visual Studio有一个名称相似的选项，并且对这两个概念进行了类似的合并。他们称其为“执行字符集”，但他们解释该选项的行为为：
执行字符集是在所有预处理步骤之后输入到编译阶段的程序文本所使用的编码。
所以...什么是海湾合作委员会的执行字符集？好吧，因为他们的文档将“执行字符集”与“窄字符串编码”混淆了，所以几乎不可能知道。
那么，该标准对GCC的行为有何要求？好吧，以您引用的规则为准。字符文字中的单个通用字符名称将是achar或an int，并且仅当通用字符名称为不在执行字符集中的字符命名时才是后者。因此，系统的执行字符集不可能包含比char允许位更多的字符。
也就是说，GCC的执行字符集不能完全使用Unicode。它必须是Unicode的某些子集。它可以选择将其作为Unicode的子集，其UTF-8编码占1 char，但它可以尽可能地大。
尽管我将其视为GCC的问题，但从技术上讲，它也是C ++规范中的问题。您引用的段落也将编码机制（即：什么char意思）与执行字符集（即：可以存储哪些字符）结合起来。
通过添加以下措辞可以识别并解决此问题：
不可编码字符文字是一种字符字面量，其c字符序列由单个c字符组成，该字符不是数字转义序列，并且指定了一个字符，该字符在文本的关联字符编码中缺乏表示或不能编码为单个代码单元。多字符字面量是一种字符字面量，其c字符序列由多个c字符组成。不可编码字符文字或多字符文字的编码前缀应不存在或为L。此类字符文字有条件地得到支持。
当这些建议作为（并被接受）作为CWG问题的解决方案时，它们也追溯适用于该标准的早期版本。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句