为什么在C11中使用丑陋的关键字？

我目前正在阅读C11规范的草案。新引入的关键字：_Bool, _Alignof, _Atomic都感觉像是自定义扩展名，而不是标准的保留关键字，如struct, union, int。

我意识到该标准基本上由标准化扩展组成...但是，这真是太糟糕了！也许我们很快就会__Long_Long_Reallylong_Integer_MSVC_2020_t以标准为最终结局！

非标准代码的向后兼容性是关键字新样式的唯一原因吗？

c keywords

— 沃拉克
source

不，我不会担心像这样的长类型。_，az，AZ和0-9的字母和数字组合的数量表示它们可能很短并且很难记住。

— 尼尔，

通常在相关的标准库头文件中定义每个关键字的漂亮同义词。例如，任何C11实现的<stdbool.h>头文件都必须包含预处理程序宏，例如#define bool _Bool。这是一个很好的解决方案，因为它保留了向后兼容性，但允许任何新代码（包括新头文件）使用更具吸引力的语法。

— andrew.punnett 2014年

Answers:

我认为与完全标准的代码向后兼容是一个更重要的原因。

如果添加一个可能在以前的代码中用作合法标识符的关键字，则会造成很多麻烦，可能会产生细微的错误，尤其是在C语言中，该语言具有某种复杂的解析规则。

如果将这些标识符用作某个地方的公共接口，则会给所有不幸的库的用户增加痛苦，他们可能根本不使用C，而是从Ruby或Python等调用该库。

这就是为什么新关键字必然看起来不太像漂亮的单词，而更像是螺栓连接的骇客，人们已经有较小的机会将其用于其他目的。

— 9000
source

应当指出，问题是关于C而不是C ++的问题。您的答案涵盖了一个新的支持类型将被命名为避免与Bool遗留代码中的自定义类型发生冲突的原因，该遗留代码被普遍接受为布尔值，但实际上并未成为C标准的一部分，因此该假设不安全使。

— 拉姆猎犬，2013年

@Ramhound，恕我直言，bool它将更符合C的精神。而且，我对此答案并不完全相信，因为非标准代码也可能使用丑陋的单词。更改单词的样式会使标准单词一眼就很难识别。

— Vorac

@Vorac：问题在于，如果bool无条件地将其添加到语言中，则所有具有其自己的（完全合法）版本的项目bool都将停止编译。这将严重损害对语言修订的接受。这就是从保留集中获取所有新标识符的原因（因此以开头_[capital]）。由于对bool自身的需求也很大，因此已在中添加typedef _Bool bool了它<stdbool.h>。

— 巴特·范·英根·谢瑙

@BartvanIngenSchenau-允许人们将自己的布尔值的typedef替换为包含在其中的值，stdbool.h或将其typedef更新为新的类型以支持其遗留代码。

— 拉姆猎犬，

@Ramhound-变量与新的C11关键字冲突的人也可能会“因此不使用它？”。有一个编译标志std = xxx可以防止与新语言标准的任何冲突。

— 踏板车

以下划线和大写字母开头的名称（以及带有双下划线的任何名称）保留用于以前的标准中的编译器/标准库实现。

从 C89和C99的保留标识符中：

还为实现者保留的是所有以下划线开头的外部标识符，以及所有其他以下划线开头，后跟大写字母或下划线的其他标识符。

因此，从理论上讲，这些新关键字不应在以前编写的任何代码中使用，并且比任何简单名称都可以提供更好的向后兼容性，这可能是唯一原因。

— 多蒂
source

您应该引用并可能链接到或命名适当的标准部分，以便其他人可以快速验证您的声明。这将改善您的答案。

— SpaceTrucker 2013年