问题
I was having a look through some open source C++ code and notice a lot of double under scores where used 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 code styles? I would think that I makes it hard to read.
回答1:
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.
回答2:
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.
回答3:
According to the C++ Standard, identifiers starting with one underscore are reserved for libraries. Identifiers starting with two underscores are reserved for compiler vendors.
回答4:
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.
回答5:
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.
回答6:
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.
回答7:
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, that page's claim seems to be unfounded
I searched a few C++ and C standards, and was unable to find any mention of underscores being restricted to the compiler's internal use.
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.
TL;DR: double underscores are reserved to the implementation
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.
来源：https://stackoverflow.com/questions/224397/why-do-people-use-double-underscore-so-much-in-c