Hello, Jack!
You wrote on Tue, 16 Aug 2005 22:19:54 -0500:
JK> All symbols beginning with an underscore followed by a lower case
JK> letter ("_a" through "_z") are also reserved for the implementation at
JK> file scope.
Actually, this one is wrong, my mistake in quoting from memory instead
of looking it up in the standard. All identifiers beginning with an
'_' are reserved at file scope, so "_0" through "_9" and just plain
"_" are reserved outside of a block.
If I unerstand you right, standard also doesn't recommend these type of
symbols in your own libraries, application etc.? Also I met this in many
SDK, developed by many respected companies.
When is says "reserved for the implementation" it means exactly that,
and your applications and libraries are not part of the
implementation.
Third parties who develop libraries for distribution certainly don't
want their users complaining that including one of their header files
or linking to one of their libraries causes the compile or link to
break, or even worse, the program builds but suddenly has "strange"
errors. Such libraries are often written by the compiler implementer,
in which case they have a perfect right to use those symbols, or for a
particular compiler and the vendor has tested it to make sure there
are no conflicts.
JK> If you look at a header supplied by your compiler, you might see that
JK> it includes something like this at the top:
With best regards, Roman Mashak. E-mail: (e-mail address removed)
If you do you violate the implementation name space, the C standard
doesn't define what will happen. Most likely any such identifier that
you use won't match one used by your implementation and the program
will work just fine. If the name does clash, you may get the compiler
or linker errors I mentioned above, or the strange problems.
Here are three lines from the stdio.h standard header supplied with
Microsoft Visual C++ 6.0:
#ifndef _INC_STDIO
#define _INC_STDIO
....and:
#endif /* _INC_STDIO */
So what do you think will happen if I use that implementation on this
source file:
#include <stdio.h>
int main(void)
{
int _INC_STDIO = 0;
return _INC_STDIO;
}
???
Replace the string "_INC_STDIO" with nothing, and see what the
compiler has to work with after the preprocessor phase.
The point is, while there are a few cases where you can use a leading
underscore, it's not worth remembering the rules. Just never define
any identifier, including macros, in your programs that begin with an
underscore and you'll never have that particular problem. There is
absolutely no compelling need or any possible gain to doing so.
