What are the rules about using an underscore in a C++ identifier?

Question

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?

Answer 1

The following characters are legal as the first character of an identifier, or any subsequent character:

_ a b c d e f g h i j k l m
n o p q r s t u v w x y z
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z

The following characters are legal as any character in an identifier except the first:

0 1 2 3 4 5 6 7 8 9

Microsoft also warns,

Use of two sequential underscore characters ( __ ) at the beginning of an identifier, or a single leading underscore followed by a capital letter, is reserved for C++ implementations in all scopes. You should avoid using one leading underscore followed by a lowercase letter for names with file scope because of possible conflicts with current or future reserved identifiers.

Answer 2

Yes, underscores may be used anywhere in an identifier. I believe the rules are: any of a-z, A-Z, _ in the first character and those + 0-9 for following characters.

Underscore prefixes are common in C code -- a single underscore means "private", and double underscores are usually reserved for use by the compiler.

Answer 3

From MSDN:

Use of two sequential underscore characters ( __ ) at the beginning of an identifier, or a single leading underscore followed by a capital letter, is reserved for C++ implementations in all scopes. You should avoid using one leading underscore followed by a lowercase letter for names with file scope because of possible conflicts with current or future reserved identifiers.

This means that you can use a single underscore as a member variable prefix, as long as it's followed by a lower-case letter.

This is apparently taken from section 17.4.3.1.2 of the C++ standard, but I can't find an original source for the full standard online.

See also this question.

Answer 4

The rules:

• Reserved in any scope, including for use as implementation macros:
  • identifiers beginning with an underscore and an uppercase letter
  • identifiers containing adjacent underscores (or "double underscore")
• Reserved in the global namespaces:
  • 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.2.1 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.

Some additional classes of identifier names are reserved for future extensions to the C language or the POSIX.1 environment. 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 the C or POSIX standards, so you should avoid these names.

• Names beginning with a capital 'E' followed a digit or uppercase letter:
  • may be used for additional error code names. See Error Reporting.
• 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 that end with '_t' are reserved
  • for additional type names.

---

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.

Answer 5

The glibc manual page about that can be found at http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html

Edit: see also http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html

Answer 6

The reserving of the suffix '_t' is a real surprise.

Answer 7

As for the other part of the question, it's common to put the underscore at the end of the variable name to not clash with anything internal.

I do this even inside classes and namespaces because name mangling is implementation-defined and it is possible that class_name::_variable_name would be mangled into something starting with a _ (because _variable_name starts with a _). class_name::variable_name_ however won't ever get mangled that way.

Answer 8

int S;
int ___S; // RESERVED FOR COMPILER USAGE
int S___;
int _S; // OS & LIBRARIES
int ___S; // RESERVED FOR COMPILER USAGE
int S___;
int _S; // OS & LIBRARIES
int 1___;//error: expected identifier
int 1___;//error: expected identifier int S;
//int  ___; // Reserved