I was taking a look through some open-source C++ code and I noticed a lot of double underscores used within in the code, mainly at the start of variable names.
return __CYGWIN__;
Just wondering: Is there a reason for this, or is it just some people's code styles? I would think that it makes it hard to read.
From Programming in C++, Rules and Recommendations :
The use of two underscores (`__') in identifiers is reserved for the compiler's internal use according to the ANSI-C standard.
Underscores (`_') are often used in names of library functions (such as "_main" and "_exit"). In order to avoid collisions, do not begin an identifier with an underscore.
Unless they feel that they are "part of the implementation", i.e. the standard libraries, then they shouldn't.
The rules are fairly specific, and are slightly more detailed than some others have suggested.
All identifiers that contain a double underscore or start with an underscore followed by an uppercase letter are reserved for the use of the implementation at all scopes, i.e. they might be used for macros.
In addition, all other identifiers which start with an underscore (i.e. not followed by another underscore or an uppercase letter) are reserved for the implementation at the global scope. This means that you can use these identifiers in your own namespaces or in class definitions.
This is why Microsoft use function names with a leading underscore and all in lowercase for many of their core runtime library functions which aren't part of the C++ standard. These function names are guaranteed not to clash with either standard C++ functions or user code functions.
According to the C++ Standard, identifiers starting with one underscore are reserved for libraries. Identifiers starting with two underscores are reserved for compiler vendors.
The foregoing comments are correct. __Symbol__ is generally a magic token provided by your helpful compiler (or preprocessor) vendor. Perhaps the most widely-used of these are __FILE__ and __LINE__, which are expanded by the C preprocessor to indicate the current filename and line number. That's handy when you want to log some sort of program assertion failure, including the textual location of the error.
The top voted answer cites Programming in C++: Rules and Recommendations:
"The use of two underscores (`__') in identifiers is reserved for the compiler's internal use according to the ANSI-C standard."
However, after reading a few C++ and C standards, I was unable to find any mention of underscores being restricted to just the compiler's internal use. The standards are more general, reserving double underscores for the implementation.
C++ (current working draft, accessed 2019-5-26) states in lex.name:
- 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.
Although this question is specific to C++, I've cited relevant sections from C standards 99 and 17:
C99 section 7.1.3
- 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.
C17 says the same thing as C99.
For C/C++, the implementation loosely refers to the set resources necessary to produce an executable from user source files. This includes:
There are a number of different C++ implementations mentioned on Wikipedia. (no anchor link, ctrl+f "implementation")
It's something you're not meant to do in 'normal' code. This ensures that compilers and system libraries can define symbols that won't collide with yours.
In addition to libraries which many other people responded about, Some people also name macros or #define values for use with the preprocessor. This would make it easier to work with, and may have allowed bugs in older compilers to be worked around.
Like others mentioned, it helps prevent name collision and helps to delineate between library variables and your own.