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):
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.165
165) Such names are also reserved in namespace
::std(17.4.3.1).
The C++ language is based on the C language (1.1/2, C++03), and C99 is a normative reference (1.2/1, C++03), so it's useful to know the restrictions from the 1999 C Standard (although they do not apply to C++ directly):
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.154
- 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.154) The list of reserved identifiers with external linkage includes
errno,math_errhandling,setjmp, andva_end.
Other restrictions might apply. For example, the POSIX standard reserves a lot of identifiers that are likely to show up in normal code:
E followed a digit or uppercase letter:is or to followed by a lowercase letterLC_ followed by an uppercase letterf or l are reservedSIG followed by an uppercase letter are reservedSIG_ followed by an uppercase letter are reservedstr, mem, or wcs followed by a lowercase letter are reservedPRI or SCN followed by any lowercase letter or X are reserved_t are reservedWhile 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.
lerance does not become a real verb that can be applied to characters. Also note it is only reserved in global scope (C)_or the standard namespace (C++) so you can have function variables with this name without breaking the rule. –
Regeniaregensburg getopt_long() is an offender of all rules: it defines macros no_argument, required_argument and optional_argument. –
Posturize _Bool and _Imaginary don't exist in C++? The C++ language are defined explicitly, not in terms of "edits" to C, otherwise the standard could be much shorter! –
Psychosurgery 7.1.3 Reserved identifiers. Please re-read. –
Regeniaregensburg serialVersionUID), and certainly no standards like variables ending in _t are reserved, because the language was designed such that everything is in a namespace. Are you saying that any language that can be compiled to machine code on multiple platforms would need to have these reserved variable name standards? –
Meyeroff #ifndef __CPP_EITHER/#define __CPP_EITHER(x,y) x/#endif, but an implementation that understood the directive could use it to improve code generation in cases where it could tell y would be more efficient than x (in cases where it couldn't tell, it could simply use x). –
Stedfast tofoo for any identifier foo beginning with a letter, including lerance. If that happens and it causes a clash with your own global, well, you were warned. The practical impact to you is small, but it gives POSIX and implementers breathing room to add stuff without endless quibbling. –
Chemmy In addition, some identifiers are reserved for use by C++ implementations and **shall not be used otherwise**; no diagnostic is required. –
Regeniaregensburg For the purposes of this document, the terms and definitions given in ISO/IEC 2382-1:1993, the terms, definitions, and symbols given in ISO 80000-2:2009, and the following apply. You can search for these terms here: iso.org/obp/ui => is required to be not . –
Regeniaregensburg If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program. –
Regeniaregensburg behavior for which this document imposes no requirements. –
Regeniaregensburg ___) always count as having a double underscore? I... believe it should? But empirical evidence on my end shows that some people may find a triple underscore to be acceptable. –
Dill Each identifier that contains a double underscore __ If you have a triple it contains a double! –
Regeniaregensburg The rules to avoid collision of names are both in the C++ standard (see Stroustrup book) and mentioned by C++ gurus (Sutter, etc.).
Because I did not want to deal with cases, and wanted a simple rule, I have designed a personal one that is both simple and correct:
When naming a symbol, you will avoid collision with compiler/OS/standard libraries if you:
Of course, putting your code in an unique namespace helps to avoid collision, too (but won't protect against evil macros)
(I use macros because they are the more code-polluting of C/C++ symbols, but it could be anything from variable name to class name)
#define _WRONG
#define __WRONG_AGAIN
#define RIGHT_
#define WRONG__WRONG
#define RIGHT_RIGHT
#define RIGHT_x_RIGHT
From the n3242.pdf file (I expect the final standard text to be similar):
17.6.3.3.2 Global names [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.12) 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.
But also:
17.6.3.3.5 User-defined literal suffixes [usrlit.suffix]
Literal suffix identifiers that do not start with an underscore are reserved for future standardization.
This last clause is confusing, unless you consider that a name starting with one underscore and followed by a lowercase letter would be Ok if not defined in the global namespace...
__WRONG_AGAIN__ contains two consecutive underscores (two at the beginning, and two at the end), so this is wrong according to the standard. –
Crawly WRONG__WRONG contains two consecutive underscores (two in the middle), so this is wrong according to the standard –
Crawly __attribute__ for GCC). –
Centrality 1234567L or 4.0f; IIRC this refers to ohttp://en.cppreference.com/w/cpp/language/user_literal –
Antiperistalsis Why is there any problem of having two consecutive underscores in the middle according to the standard? Because the standard say those are reserved. This is not an advice on good or bad style. It's a decision from the standard. Why they decided this? I guess the first compilers already used such conventions informally before standardization. –
Crawly 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.
__ is reserved for implementations, MSVC says that they only use it at the beginning of identifiers and you are free to use it elsewhere. Writing such code would mean it is not portable but compliant with MSVC. –
Broadleaf 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 I then only have to remember one rule (compared to "at the end of the name in global scope, and the beginning of the name everywhere else").
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 the 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.
_Foo, though by doing so you're relying on nonstandard implementation details and thus risk having your code broken by future versions of the language/standard library implementation/OS. –
Provoke Firstly, the rules in current working draft are laid out in [lex.name] p3:
In addition, some identifiers appearing as a token or preprocessing-token are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.
- Each identifier that contains a double underscore
__or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.- Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
Furthermore, the standard library reserves all names defined in namespace std and some zombie names; see [reserved.names.general].
As the accepted answer has pointed out, there may be other parts of the implementation, like the POSIX standard, which limit the identifiers you can use.
Each identifier with file scope described in the header section is reserved for use as an identifier with file scope in the same name space if the header is included.
ANY Header [reserves] Suffix
_t
In C++, almost all problems associated with POSIX can be avoided through namespaces.
This is also why the C++ standard can add tons of symbols like std::enable_if_t without breaking POSIX compatibility.
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
}
The above rules for y apply to both named and unnamed namespaces.
Either way, in the following namespace, the rules of the global namespace
no longer apply (see [namespace.unnamed]).
The above rules for y also apply to identifiers in classes, functions, etc.; anything but global scope.
Even though assert isn't used like a function-style macro here, the name is reserved. This is also why proposal P2884 contemplates making it a keyword in C++26, with some success so far.
To be safe, always avoid double underscores, and always avoid nams with leading underscores. The latter are okay in some cases, but it's difficult to memorize these rules, and it's better to be safe than sorry.
_ in itself?Some people use _ to indicate that some variable or function parameter isn't used. However, you can avoid this with:
void foo(T _) { /* ... */ }
// replace with:
void foo(T) { /* ... */ }
std::scoped_lock _{mutex};
// replace with:
std::scoped_lock lock{mutex};
You can also cast a parameter p to void like (void)p, if this is about silencing warnings about p being unused, and you need C compatibility. See Why cast unused return values to void?.
© 2022 - 2024 — McMap. All rights reserved.