Re:The GNU C Library version 2.19 is now available
by letzjuc on Sunday February 09, 2014 @09:56AM
(#7205702)
In ISO C (7.1.3):
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.
In ISO C++ (17.4.3.2.1):
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
In both (7.1.3 / 17.4.3.2.1):
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.
The rule of thumb is never give a name that start with an underscore (simple, right?).
That goes for C and C++. In C++ people think that they are a bit safer because of namespaces, but I've seen it create problems when someone writes an using directive in a header file (dont do this). It will work on their project but break yours. And finding which header is causing this is a nightmare in small-medium sized projects. In big projects it deserves to get someone fired.
Note: if you really want/need to break this rule, choose a name that will not conflict with anything! E.g. in Boost file guards have a randomly generated character sequence appended at their end. They are not doing anything "illegal", but is a policy they have just to be sure.
In ISO C++ (17.4.3.2.1): Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
In both (7.1.3 / 17.4.3.2.1): 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.
The rule of thumb is never give a name that start with an underscore (simple, right?).
That goes for C and C++. In C++ people think that they are a bit safer because of namespaces, but I've seen it create problems when someone writes an using directive in a header file (dont do this). It will work on their project but break yours. And finding which header is causing this is a nightmare in small-medium sized projects. In big projects it deserves to get someone fired.
Note: if you really want/need to break this rule, choose a name that will not conflict with anything! E.g. in Boost file guards have a randomly generated character sequence appended at their end. They are not doing anything "illegal", but is a policy they have just to be sure.