在 C++ 中使用下划线的规则是什么？ 标识符？

Question

在 C++ 中，使用某种前缀来命名成员变量是很常见的，以表示它们是成员变量，而不是局部变量或参数。 如果您有 MFC 背景，您可能会使用 m_foo。 我偶尔也见过 myFoo。

C#（或者可能只是 .NET）似乎建议仅使用下划线，如 _foo 中所示。 C++ 标准允许这样做吗？

Answer 1

规则（在 C++11 中没有更改）：

• 在任何范围内保留，包括用作实现 宏：
  • 以下划线开头的标识符，后跟一个大写字母
  • 包含相邻下划线（或“双下划线”）的标识符

• 保留在全局命名空间中：
  • 以下划线开头的标识符
• 此外，std 命名空间中的所有内容都被保留。 （不过，您可以添加模板专业化。）

来自 2003 C++ 标准：

17.4.3.1.2 全局名称 [lib.global.names]

某些名称和函数签名集始终保留给实现：

• 每个包含双下划线 (__) 或以下划线后跟大写字母 (2.11) 开头的名称均保留给实现以供任何使用。
• 每个以下划线开头的名称都保留给实现，以用作全局命名空间中的名称。¹⁶⁵

¹⁶⁵⁾ 这些名称也在命名空间 ::std (17.4.3.1) 中保留。

C++ 语言基于 C 语言（1.1/2、C++03），而 C99 是规范性参考（1.2/1、C++03），因此了解 1999 C 标准的限制很有用（尽管它们并不直接适用于 C++）：

7.1.3 保留标识符

每个标头声明或定义其关联子条款中列出的所有标识符，并且
可选地声明或定义在其关联的未来库方向子条款中列出的标识符和标识符，这些标识符始终保留用于任何用途或用作文件范围标识符。

• 以下划线和大写字母或其他字母开头的所有标识符
  下划线始终保留用于任何用途。
• 所有以下划线开头的标识符始终保留用作标识符
  文件范围位于普通名称空间和标记名称空间中。
• 以下任何子条款中的每个宏名称（包括未来的库
  如果包含任何相关标头，则保留按指定使用；
  除非另有明确说明（见7.1.4）。
• 以下任何子条款中具有外部链接的所有标识符（包括
  未来的图书馆方向）始终保留用作外部标识符
  链接。¹⁵⁴
• 以下任何子条款中列出的具有文件范围的每个标识符（包括
  未来的库方向）被保留用作宏名称和标识符
  如果包含任何关联的标头，则文件范围位于同一名称空间中。

没有保留其他标识符。 如果程序在a中声明或定义了一个标识符
保留它的上下文（7.1.4 允许的除外），或定义一个保留的
标识符作为宏名称，行为未定义。

如果程序删除（使用#undef）第一个标识符中的任何宏定义
上面列出的组，行为未定义。

¹⁵⁴⁾ 具有外部链接的保留标识符列表包括 errno、math_errhandling、setjmp 和 <代码>va_end。

其他限制可能适用。 例如，POSIX 标准保留了许多可能出现在普通代码中的标识符：

• 以大写 E 开头的名称，后跟数字或大写字母：
  • 可用于其他错误代码名称。
• 以 is 或 to 开头，后跟小写字母的名称：
  • 可用于其他字符测试和转换功能。
• 以 LC_ 开头，后跟大写字母的名称：
  • 可用于指定区域设置属性的其他宏。
• 所有以 f 或 l 为后缀的现有数学函数的名称均被保留：
  • 分别对应对 float 和 long double 参数进行操作的相应函数。
• 以 SIG 开头后跟大写字母的名称被保留：
  • 获取其他信号名称。
• 以 SIG_ 开头后跟大写字母的名称被保留：
  • 用于其他信号操作。
• 以 str、mem 或 wcs 开头且后跟小写字母的名称被保留：
  • 用于其他字符串和数组函数。
• 以 PRI 或 SCN 开头，后跟任何小写字母或 X 的名称被保留：
  • 用于其他格式说明符宏
• 以 _t 结尾的名称被保留：
  • 用于其他类型名称。

虽然现在将这些名称用于您自己的目的可能不会造成问题，但它们确实会增加与该标准的未来版本发生冲突的可能性。

---

就我个人而言，我只是不使用下划线开头标识符。 我的规则的新增内容：不要在任何地方使用双下划线，这很容易，因为我很少使用下划线。

在对本文进行研究后，我不再以 _t 结尾我的标识符
因为这是 POSIX 标准保留的。

关于任何以 _t 结尾的标识符的规则让我很惊讶。 我认为这是一个 POSIX 标准（尚未确定），正在寻求澄清和官方章节。 这是来自 GNU libtool 手册，列出了保留名称。

CesarB 提供了以下链接到 POSIX 2004 保留符号和注释'许多其他保留的前缀和后缀......可以在那里找到。 这
POSIX 2008 保留符号在这里定义。 这些限制比上述限制更为细致。

Answer 2

避免名称冲突的规则既包含在 C++ 标准中（参见 Stroustrup 的书），也由 C++ 大师（Sutter 等）提到过。

个人规则

因为我不想处理案例，并且想要一个简单的规则，所以我设计了一个既简单又正确的个人规则：

命名符号时，如果您满足以下条件，则可以避免与编译器/操作系统/标准库发生冲突：

• 永远不要以下划线开头的符号
• 永远不要命名内部包含两个连续下划线的符号。
  

当然，将代码放在唯一的命名空间中也有助于避免冲突（但不能防止邪恶的宏）

一些示例

（我使用宏是因为它们对 C/C++ 符号的代码污染更大，但它可以是从变量名到类名的任何内容）

#define _WRONG
#define __WRONG_AGAIN
#define RIGHT_
#define WRONG__WRONG
#define RIGHT_RIGHT
#define RIGHT_x_RIGHT

摘自 C++0x 草稿

来自 n3242.pdf 文件（我希望最终的标准文本类似）：

17.6.3.3.2 全局名称 [global.names]

某些名称和函数签名集始终保留给实现：

— 每个包含双下划线 _ _ 或以下划线后跟大写字母 (2.12) 开头的名称都保留给实现以供任何使用。

— 每个以下划线开头的名称都保留给实现，以用作全局命名空间中的名称。

但是也：

17.6.3.3.5 用户定义的文字后缀 [usrlit.suffix]

不以下划线开头的文字后缀标识符保留用于将来的标准化。

最后一个子句令人困惑，除非您认为如果未在全局命名空间中定义，则以一个下划线开头并后跟一个小写字母的名称是可以的...

Answer 3

来自 MSDN：

在标识符开头使用两个连续下划线字符 ( __ ) 或单个前导下划线后跟大写字母，是为所有范围内的 C++ 实现保留的。 您应该避免使用一个前导下划线后跟一个小写字母作为具有文件范围的名称，因为可能与当前或将来的保留标识符发生冲突。

这意味着您可以使用单个下划线作为成员变量前缀，只要它后面跟着一个小写字母即可。

这显然取自 C++ 标准的第 17.4.3.1.2 节，但我无法在线找到完整标准的原始来源。

另请参阅此问题。

Answer 4

至于问题的其他部分，通常将下划线放在变量名称的末尾，以免与任何内部内容发生冲突。

我什至在类和命名空间内也这样做，因为这样我只需要记住一条规则（与“在全局范围内的名称末尾，以及其他地方的名称开头”相比）。

Answer 5

是的，下划线可以用在标识符中的任何地方。 我相信规则是：第一个字符中的任何 az、AZ、_ 以及后续字符中的 +0-9。

下划线前缀在 C 代码中很常见——单下划线表示“私有”，双下划线通常保留供编译器使用。

Answer 6

首先，当前工作草案中的规则在 [lex.name] p3< 中列出/a>:

此外，一些显示为令牌或预处理令牌的标识符保留供C++实现使用，不得以其他方式使用； 无需诊断。

• 每个包含双下划线 __ 或以下划线后跟大写字母开头的标识符都保留给实现以供任何使用。
• 以下划线开头的每个标识符都保留给实现，以用作全局命名空间中的名称。

此外，标准库保留了namespace std中定义的所有名称和一些僵尸名称； 请参阅[reserved.names.general]。

那么 POSIX 呢？

正如已接受的答案所指出的那样，实现的其他部分（例如 POSIX 标准）可能会限制您可以使用的标识符。

如果包含标头，则标头部分中描述的每个具有文件范围的标识符都被保留用作同一名称空间中具有文件范围的标识符。

任意标头 [保留] 后缀 _t

- POSIX 2008 标准，2.2.2

在 C++ 中，几乎所有与 POSIX 相关的问题都可以通过命名空间来避免。
这也是为什么 C++ 标准可以在不破坏 POSIX 兼容性的情况下添加大量符号，例如 std::enable_if_t 。

可视化

int x;      // OK
int x_;     // OK
int _x;     // RESERVED
int x__;    // RESERVED (OK in C)
int __x;    // RESERVED
int _X;     // RESERVED
int assert; // RESERVED (macro name)
int x_t;    // RESERVED (only by POSIX)

namespace {
int y;      // OK
int y_;     // OK
int _y;     // OK
int y__;    // RESERVED (OK in C, ignoring namespaces)
int __y;    // RESERVED
int _Y;     // RESERVED
int assert; // RESERVED (macro name)
int y_t;    // OK
}

上述 y 规则适用于命名和未命名命名空间。
不管怎样，在下面的命名空间中，遵循全局命名空间的规则
不再适用（请参阅[namespace.unnamed]）。

上述 y 规则也适用于类、函数等中的标识符； 除了全球范围之外的任何东西。

尽管 assert 在这里不像函数式宏那样使用，但该名称是保留的。 这也是提案 P2884 的原因考虑将其作为 C++26 中的关键字，到目前为止取得了一些成功。

建议的做法

为了安全起见，请始终避免使用双下划线，并始终避免带有前导下划线的 nam。
后者在某些情况下是可以的，但记住这些规则很困难，安全总比后悔好。

_ 本身怎么样？

有些人使用 _ 来表示未使用某些变量或函数参数。 但是，您可以通过以下方式避免这种情况：

void foo(T _) { /* ... */ }
// replace with:
void foo(T) { /* ... */ }

std::scoped_lock _{mutex};
// replace with:
std::scoped_lock lock{mutex};

您还可以将参数 p 强制转换为 void，如 (void)p，如果这是关于静音警告关于 p 未使用，并且您需要 C 兼容性。 请参阅为什么将未使用的返回值转换为 void？。