在C ++标识符中使用下划线有什么规则？ [英] What are the rules about using an underscore in a C++ identifier?

问题描述

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

C＃（或者可能只是.NET）似乎建议使用下划线，如 _foo 。

解决方案

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

• 在任何范围内保留，包括用作实现宏：
  
  
  
  
  
  
  $ b
  • 在全局命名空间中保留：
    
    
    
    
    • 以下划线开头的标识符
    
    
  
  
  • 此外， std 命名空间中的所有内容都被保留。
  
  
  
  
  

  从2003 C ++标准：

  
  

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

  
  
  

  某些名称和函数签名总是保留给实现：

  
  
  

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

  
  
  

  ^165）这些名称也保留在namespace :: std（17.4.3.1）中。

  
  

  因为C ++基于C标准（1.1 / 2，C ++ 03），C99是标准参考1，C ++ 03）这些也适用于1999 C标准：

  
  

  7.1.3保留的标识符

  
  
  

  每个头声明或定义其相关子段中列出的所有标识符，
  可选择声明或定义在其相关的未来库方向子句中列出的标识符和标识符，或用作文件范围标识符。

  
  
  

  
  
  • 以下划线开头，大写字母或另一个
    下划线的所有标识符
  
  
  • 以下划线开头的所有标识符始终保留作为标准符
    ，并在普通和标记名空格中使用文件范围。
  
  
  • 以下任何子段落中的每个宏名称（包括将来的库
    方向）保留供指定使用，如果包含其任何相关联的标题;
  
  
  • 以下任何子条款（包括
    未来库指南）中具有外部链接的所有标识符始终为保留用作外部
    链接的标识符。 ¹⁵⁴
  
  
  • 每个标识符包含以下任何子条目中列出的文件范围（包括
    未来库指导）保留用作宏名称和作为标识符的
    文件范围在同一名称空间（如果包含任何相关联的头文件）。
  
  

  
  
  

  不保留其他标识符。如果程序在
  上下文中声明或定义了一个标识符（除了7.1.4允许的），或者将一个保留的
  标识符定义为宏名称，那么行为是未定义的。

  
  
  

  如果程序删除（$ #undef ）任何第一个标识符的宏定义
  

  
  
  

  ^154）具有外部链接的保留标识符列表包括 errno ， math_errhandling ， setjmp 和 va_end 。

  
  

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

  
  
  
  
  
  • 以大写'E '后跟数字或大写字母：
    
    
    
    
    • 可用于其他错误代码名称。
    
    
  
  
  • 以'is'或'to'开头，后接小写字母
    
    
    
    
    • 的名称可用于额外的字符测试和转换函数。
    
    
  
  
  • 以LC_开头，后跟大写字母的名称
    
    
    
    
  
  
  • 可用于指定区域设置属性的其他宏。 '或'l'保留
    
    
    
    
    • 分别用于对float和long双引号操作的相应函数。
    
    
  
  
  • 以SIG开头并以大写字母开头的名称保留为
    
    
    
    
    • 用于附加信号名称。 / li>
      
  
  
  • 以SIG_开头并以大写字母开头的名称已保留
    
    
    $ b $
    
    • 以'str'，'mem'或'wcs'开头的名称，后跟一个小写字母保留
      
      
      
      
      • 用于额外的字符串和数组函数。
      
      
    
    
    • 以'PRI'或'SCN'开头，后跟任意小写字母或'X'的名称保留
      
      
      
      
      • 用于其他格式说明符宏
      
      
    
    
    • 以_t结尾的名称已保留
      
      
      
      
      • 。
      
      
    
    
    
    
    

    现在使用这些名称可能不会导致

    
    
    

    ---

    
    
    

    我个人只是不启动标识符带下划线。

    
    
    

    在对这篇文章进行研究后，我不再结束我的标识符了'_t'
    因为这是由POSIX标准保留的。

    
    
    

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

    
    
    

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

    
    

    It's common in C++ to name member variables with some kind of prefix to denote the fact that they're member variables, rather than local variables or parameters. If you've come from an MFC background, you'll probably use m_foo. I've also seen myFoo occasionally.

    C# (or possibly just .NET) seems to recommend using just an underscore, as in _foo. Is this allowed by the C++ standard?

    解决方案

    The rules (which did not change in C++11):

    • Reserved in any scope, including for use as implementation macros:
      • identifiers beginning with an underscore followed immediately by an uppercase letter
      • identifiers containing adjacent underscores (or "double underscore")
    • Reserved in the global namespace:
      • identifiers beginning with an underscore
    • Also, everything in the std namespace is reserved. (You are allowed to add template specializations, though.)

    From the 2003 C++ Standard:

    17.4.3.1.2 Global names [lib.global.names]

    Certain sets of names and function signatures are always reserved to the implementation:

    • Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
    • Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.¹⁶⁵

    ¹⁶⁵⁾ Such names are also reserved in namespace ::std (17.4.3.1).

    Because C++ is based on the C standard (1.1/2, C++03) and C99 is a normative reference (1.2/1, C++03) these also apply, from the 1999 C Standard:

    7.1.3 Reserved identifiers

    Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.

    • All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
    • All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
    • Each macro name in any of the following subclauses (including the future library directions) is reserved for use as specified if any of its associated headers is included; unless explicitly stated otherwise (see 7.1.4).
    • All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage.¹⁵⁴
    • Each identifier with file scope listed in any of the following subclauses (including the future library directions) is reserved for use as a macro name and as an identifier with file scope in the same name space if any of its associated headers is included.

    No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

    If the program removes (with #undef) any macro definition of an identifier in the first group listed above, the behavior is undefined.

    ¹⁵⁴⁾ The list of reserved identifiers with external linkage includes errno, math_errhandling, setjmp, and va_end.

    Other restrictions might apply. For example, the POSIX standard reserves a lot of identifiers that are likely to show up in normal code:

    • Names beginning with a capital 'E' followed a digit or uppercase letter:
      • may be used for additional error code names.
    • Names that begin with either 'is' or 'to' followed by a lowercase letter
      • may be used for additional character testing and conversion functions.
    • Names that begin with 'LC_' followed by an uppercase letter
      • may be used for additional macros specifying locale attributes.
    • Names of all existing mathematics functions suffixed with 'f' or 'l' are reserved
      • for corresponding functions that operate on float and long double arguments, respectively.
    • Names that begin with 'SIG' followed by an uppercase letter are reserved
      • for additional signal names.
    • Names that begin with 'SIG_' followed by an uppercase letter are reserved
      • for additional signal actions.
    • Names beginning with 'str', 'mem', or 'wcs' followed by a lowercase letter are reserved
      • for additional string and array functions.
    • Names beginning with 'PRI' or 'SCN' followed by any lowercase letter or 'X' are reserved
      • for additional format specifier macros
    • Names that end with '_t' are reserved
      • for additional type names.

    While using these names for your own purposes right now might not cause a problem, they do raise the possibility of conflict with future versions of that standard.

    ---

    Personally I just don't start identifiers with underscores. New addition to my rule: Don't use double underscores anywhere, which is easy as I rarely use underscore.

    After doing research on this article I no longer end my identifiers with '_t' as this is reserved by the POSIX standard.

    The rule about any identifier ending with '_t' surprised me a lot. I think that is a POSIX standard (not sure yet) looking for clarification and official chapter and verse. This is from the GNU libtool manual, listing reserved names.

    CesarB provided the following link to the POSIX 2004 reserved symbols and notes 'that many other reserved prefixes and suffixes ... can be found there'. The POSIX 2008 reserved symbols are defined here. The restrictions are somewhat more nuanced than those above.

    这篇关于在C ++标识符中使用下划线有什么规则？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！