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

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

C#(或可能只是.NET)似乎建议只使用下划线,如_foo 。 这是由C ++标准允许的吗?


规则(在C ++ 11中没有改变):

  • 保留在任何范围内,包括用作实现宏:
  • 以下划线开头的标识符紧跟着一个大写字母
  • 包含相邻下划线(或“双下划线”)的标识符
  • 保留在全局名称空间中:
  • 以下划线开头的标识符
  • 而且, std命名空间中的所有内容都是保留的。 (不过,您可以添加模板专业化。)
  • 从2003年C ++标准:

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

    某些名称和功能签名集始终保留给实施:

  • 每个包含双下划线( __ )的名称或以下划线开头且后面带有大写字母(2.11)的名称保留给实施用于任何用途。
  • 每个以下划线开头的名称都保留给实现,以用作全局名称空间中的名称
  • 这些名字也保留在namespace ::std (17.4.3.1)中。

    由于C ++基于C标准(1.1 / 2,C ++ 03),并且C99是规范性参考(1.2 / 1,C ++ 03),因此它们也适用于1999 C标准:

    7.1.3保留标识符

    每个头部声明或定义在其相关子条款中列出的所有标识符,并且可选地声明或定义其关联的未来库方向子条款中列出的标识符以及总是保留用于任何用途或用作文件范围标识符的标识符。

  • 所有以下划线和大写字母或其他下划线开头的标识符总是保留用于任何用途。
  • 所有以下划线开头的标识符总是保留用作普通标签和标签名称空间中具有文件范围的标识符。
  • 如果包含任何相关标题,则下列任何子条款中的每个宏名称(包括未来的图书馆方向)都将被保留以供指定使用; 除非另有明确说明(见7.1.4)。
  • 在下列任何条款(包括未来的图书馆方向)中,所有具有外部链接的标识符都被保留作为具有外部链接的标识符使用.154
  • 每个包含以下任何子条款(包括未来库方向)中列出的文件范围的标识符都被保留用作宏名称,并且如果包含任何相关头文件,则将其用作具有相同名称空间中的文件范围的标识符。
  • 没有其他标识符被保留。 如果程序在保留的上下文中声明或定义了一个标识符(7.1.4中允许的除外),或者将保留的标识符定义为宏名称,则行为是未定义的。

    如果程序删除(使用#undef )上面列出的第一组中的标识符的任何宏定义,则行为未定义。

    154)具有外部链接的保留标识符列表包括errnomath_errhandlingsetjmpva_end

    其他限制可能适用。 例如,POSIX标准保留了很多可能以正常代码显示的标识符:

  • 以大写字母E开头的名称后跟数字或大写字母:
  • 可能会用于其他错误代码名称。
  • 与任一开始的名字isto后跟一个小写字母
  • 可用于其他字符测试和转换功能。
  • 名称以LC_开头,后跟大写字母
  • 可用于指定语言环境属性的其他宏。
  • 所有现有数学函数的后缀名为fl都被保留
  • 用于分别对float和long double参数进行操作的相应函数。
  • SIG开头并以大写字母开头的名称将被保留
  • 获取更多信号名称。
  • SIG_开头,后跟大写字母的名称将被保留
  • 用于额外的信号动作。
  • 名称以strmemwcs开头,后面跟着小写字母
  • 用于附加的字符串和数组函数。
  • 名称以PRISCN开头,后面跟着任何小写字母或X被保留
  • 用于附加格式说明符宏
  • _t结尾的名称是保留的
  • 对于其他类型名称。
  • 尽管目前将这些名称用于自己的目的可能不会导致问题,但它们确实会提高与该标准的未来版本冲突的可能性。


    就我个人而言,我不会用下划线启动标识符。 我的规则的新增加点:不要在任何地方使用双下划线,这很容易,因为我很少使用下划线。

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

    关于以_t结尾的任何标识符的规则让我感到惊讶。 我认为这是一个POSIX标准(尚不确定)寻求澄清和正式章节和诗句。 这是来自GNU libtool手册,列出了保留的名称。

    CesarB提供了以下指向POSIX 2004保留符号的链接,并指出“许多其他保留的前缀和后缀......可以在那里找到”。 这里定义了POSIX 2008保留的符号。 这些限制比上面的限制更为细微。


    避免名称冲突的规则都在C ++标准中(参见Stroustrup书),并由C ++大师(Sutter等)提及。

    个人规则

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

    命名符号时,如果您符合以下条件,您将避免与编译器/ OS /标准库冲突:

  • 永远不要用下划线开始符号
  • 永远不要在内部使用两个连续的下划线来命名符号。
  • 当然,将你的代码放在一个唯一的命名空间中也有助于避免碰撞(但不会防止恶意的宏)

    一些例子

    (我使用的宏是因为它们是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。


    来自MSDN:

    在标识符的开头使用两个连续的下划线字符(__),或者使用单引号下划线后跟一个大写字母,在所有作用域中保留用于C ++实现。 由于可能与当前或将来保留的标识符发生冲突,因此应避免使用一个带有文件范围名称的前导下划线,后跟一个小写字母。

    这意味着只要紧跟一个小写字母,就可以使用一个下划线作为成员变量前缀。

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

    另请参阅此问题。

    链接地址: http://www.djcxy.com/p/1047.html

    上一篇: What are the rules about using an underscore in a C++ identifier?

    下一篇: What are POD types in C++?