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

是的，下划线可以在标识符中的任何位置使用。我相信规则是：第一个字符中的 a-z、A-Z、_ 中的任何一个，以及以下字符的 +0-9。

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

来自 MSDN：

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

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

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

另请参阅此问题。

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

• 保留在任何作用域中，包括用作实现宏：
  • 以下划线开头的标识符，后跟大写字母
  • 包含相邻下划线（或“双下划线”）的标识符
• 保留在全局命名空间中：
  • 以下划线开头的标识符
• 此外，命名空间中的所有内容都是保留的。（不过，您可以添加模板专用化。std

来自 2003 C++ 标准：

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

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

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

¹⁶⁵） 此类名称也保留在命名空间 （17.4.3.1） 中。::std

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

7.1.3 保留标识符

每个标头声明或定义其关联子句中列出的所有标识符，以及 （可选）声明或定义其关联的“未来库方向”子句中列出的标识符和标识符，这些标识符始终保留用于任何用途或用作文件范围标识符。

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

不保留其他标识符。如果程序在 保留的上下文（7.1.4 允许的上下文除外）或定义保留的上下文 identifier 作为宏名称，则行为未定义。

如果程序删除 （with ） 第一个标识符的任何宏定义 组，则行为未定义。#undef

^154） 具有外部链接的保留标识符列表包括 、 、 和 。errnomath_errhandlingsetjmpva_end

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

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

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

---

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

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

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

CesarB 提供了以下指向 POSIX 2004 保留符号的链接，并指出“许多其他保留的前缀和后缀......可以在那里找到'。此处定义了 POSIX 2008 保留符号。这些限制比上述限制更加微妙。

避免名称冲突的规则既在 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]

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

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

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

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

首先，现行工作草案中的规则列于[lex.name] p3：

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

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

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

POSIX呢？

正如公认的答案所指出的，实现中可能还有其他部分，例如 POSIX 标准，它们限制了您可以使用的标识符。

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

ANY 标头 [reserves] 后缀 _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
}

上述规则适用于命名命名空间和未命名命名空间。 无论哪种方式，在以下命名空间中，全局命名空间的规则 不再适用（请参阅 [namespace.unnamed]）。y

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

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

推荐做法

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

那本身呢？_

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

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

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

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