Names beginning with _ or __

According to the C++ standard, names beginning with either "__" or a single "_" followed by a capitalized alphabetic letter are "reserved to the implementation". I'm not sure what defines "implementation" here. Are we talking about, for example, STL?

Does that mean that certain include guards that are formatted as follows are illegal?

Code:

---

#define __CFooClass_h__

---

I'm pretty sure this would be illegal:

Code:

---

int _SomeGlobalInt = 0;

---

And this:

Code:

---

int __anotherGlobal = 2;

---

And also this:

Code:

---

void _SomeFunction( int param ) {}

---

Mainly I'm confused about preprocessor names (whether the underscore rule applies to them) and the lack of emphasis on the definition of 'Implementation' by the standard.

What kind of conflicts would we be looking at here? Link stage conflicts?

Thanks for reading.

Quote:

---

Originally Posted by MrDoomMaster

According to the C++ standard, names beginning with either "__" or a single "_" followed by a capitalized alphabetic letter are "reserved to the implementation". I'm not sure what defines "implementation" here. Are we talking about, for example, STL?

---

STL, and any 'C' or C++ header file that are not STL. This includes <cstdio>, <cmath>, etc.

Quote:

---

Does that mean that certain include guards that are formatted as follows are illegal?

---

These are not illegal, just that your code may conflict with an identifier that is used by the compiler.

For example, here is one that is very dangerous:

Code:

---

#define _FILE whatever
#include <cstdio>

---

There is a big chance that <cstdio> uses _FILE somewhere, and you've basically messed up compilation of <cstdio> in some way by using _FILE as your own identifier.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

These are not illegal, just that your code may conflict with an identifier that is used by the compiler.

---

You say that these are not illegal, however the standard explicitly states that it owns the rights to use them. By using them, you're basically not writing C++. How do you justify it not being illegal?

"Not illegal" == "Syntactically correct"

In other words, they are valid identifiers. If they weren't I'd expect the compiler to throw a syntax error.

Viggy

Quote:

---

Originally Posted by MrDoomMaster

You say that these are not illegal, however the standard explicitly states that it owns the rights to use them. By using them, you're basically not writing C++. How do you justify it not being illegal?

---

Section [lib.reserved.names] makes a distinction between 3 types of symbols 1) macro names, 2) global names, and 3) names with external linkage. The underscore restriction only applies to global names, not to macro names. Since the time the dinosaurs walked the earth, it's been common practice to use leading and trailing underscores in header include guard symbols. I think it be a seismic shift if it were to turn out that's illegal. Anyway, even if it's not illegal it's clear you still have a problem if an include guard symbol conflicts with a global name used by the implementation. :wave:

Quote:

---

Originally Posted by MrDoomMaster

You say that these are not illegal, however the standard explicitly states that it owns the rights to use them. By using them, you're basically not writing C++. How do you justify it not being illegal?

---

They are not illegal. If they were, you would get a syntax error. If anything, the code may be ill-formed, but not illegal.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by MrViggy

"Not illegal" == "Syntactically correct"

In other words, they are valid identifiers. If they weren't I'd expect the compiler to throw a syntax error.

Viggy

---

Just because something is "syntactically correct" doesn't mean it is legal. If I wanted to write my own implementation of STL but not make a conforming interface, sure it would be "syntactically correct" but by no means would it be a legal STL implementation. And thus it wouldn't be C++ since STL is part of the standard.

My concerns rise above simple syntactical correctness. The legality I'm talking about concerns what is explicitly reserved by the standard. Creating identifiers that start with "__" but don't cause compiler errors only do so by coincidence. You have no idea, especially between implementations, which identifiers may or may not work. Thus your code is not portable.

Quote:

---

Originally Posted by googler

The underscore restriction only applies to global names, not to macro names.

---

Thanks! I had forgotten that it only applies to global names. Thank you for reminding me.

Quote:

---

Originally Posted by googler

Section [lib.reserved.names] makes a distinction between 3 types of symbols 1) macro names, 2) global names, and 3) names with external linkage. The underscore restriction only applies to global names, not to macro names. Since the time the dinosaurs walked the earth, it's been common practice to use leading and trailing underscores in header include guard symbols. I think it be a seismic shift if it were to turn out that's illegal. Anyway, even if it's not illegal it's clear you still have a problem if an include guard symbol conflicts with a global name used by the implementation. :wave:

---

Hey guys,

I'm bringing this topic back to life because quite frankly I still feel there's a couple of things that remain unanswered.

In the quote above, googler states that it only applies to globals. If this is true, then macros obviously fall under that category too since macros do not respect scope, and thus will conflict with any global defined by the implementation anyway. Globals and macros go hand-in-hand in this situation. Am I misunderstanding a point you were trying to make, googler?

Quote:

---

Originally Posted by MrDoomMaster

Hey guys,

I'm bringing this topic back to life because quite frankly I still feel there's a couple of things that remain unanswered.

In the quote above, googler states that it only applies to globals. If this is true, then macros obviously fall under that category too since macros do not respect scope, and thus will conflict with any global defined by the implementation anyway. Globals and macros go hand-in-hand in this situation. Am I misunderstanding a point you were trying to make, googler?

---

You stated yourself that "macros do not respect scope". So you answered your own question. macros are not global in scope. They have no scope. So they obviously do not fall under the "global scope".

By the way, if you write non-std code the compiler is supposed to report an error unless the compiler vendor extended the language, in which case you might get a warning indicating that you are using a non-std extension of the language. Earlier you wrote something about "writing non-std code that is syntactically correct". I don't see how you can do that unless the compiler vendor provided you with a compiler that extends the language and you have specifically enabled the use of non-std extensions.

I'm not saying that macros are in the "global scope" category.

Googler states, if I am understanding correctly, that only global variables (not macros) can conflict with implementation defined naming conventions. So, if the implementation defines the following:

__setupSomething

If I define a global like follows:

int __setupSomething;

This should cause conflicts, as the implementation has reserved that name. Now, if I do this:

#define __setupSomething

This is no different, it will still conflict. The fact that a macro respects no scope means that it will conflict with implementation reserved names just as much as a global would.

Quote:

---

Originally Posted by MrDoomMaster

The fact that a macro respects no scope means that it will conflict with implementation reserved names just as much as a global would.

---

More than a global would, in fact, because a macro could conflict with an identifier in any namespace.

So I agree, I cannot imagine that beginning a macro with _ or __ is safer than beginning a global identifier likewise. Paul made a point of it in the first reply to this thread, actually.

If I recall correctly, this is the deal:
- You should not name macros or globals (i.e. identifiers in file scope) beginning with _
- You should not name anything beginning with __, or _ followed by a capital letter.

I think.

Quote:

---

Googler states, if I am understanding correctly, that only global variables (not macros) can conflict with implementation defined naming conventions. So, if the implementation defines the following:

---

He said nothing of the sort. Re-read his post.

Quote:

---

__setupSomething

If I define a global like follows:

int __setupSomething;

This should cause conflicts, as the implementation has reserved that name. Now, if I do this:

#define __setupSomething

This is no different, it will still conflict. The fact that a macro respects no scope means that it will conflict with implementation reserved names just as much as a global would.

---

I did not write the std so not sure why they didn't apply the restriction to macros. They just didn't for whatever reason. It might have something to do with the fact that macros are text substitutions that occur prior to compiling the code. There is a whole section of the std on the preprocessing directives. Your example is a good point; defining macros can be dangerous. C++ programmers should be avoiding them as much as possible anyway for many reasons, including but not limited to this reason. It's better to write code that actually gets compiled. Text substitutions can be messy.

Though, now that I think of it, macros have the potential to conflict with a compiler's implementation of the standard library no matter what, so maybe that's why there's no specific stipulation regarding macros.

For example, what if you put #define true false or something equally stupid before you include a standard header?

EDIT: looks like kempofighter beat me to that point.
EDIT EDIT: Never mind :)

Quote:

---

Originally Posted by kempofighter

He said nothing of the sort. Re-read his post.

---

Yes, he did say it. Quote below:

Quote:

---

Originally Posted by googler

The underscore restriction only applies to global names, not to macro names.

---

Quote:

---

Originally Posted by Hermit

Though, now that I think of it, macros have the potential to conflict with a compiler's implementation of the standard library no matter what, so maybe that's why there's no specific stipulation regarding macros.

---

But there is. The std states,

Quote:

---

1 A translation unit that includes a standard library header shall not #define or #undef names declared in any standard
library header.
2 A translation unit shall not #define or #undef names lexically identical to keywords.

---

It seems that the std's committee was just trying to establish boundaries to prevent naming conflicts. You can name a variable like so:

Code:

---

int main()
{
  int __success;
  __success = callAFunction();
  return success;
}

---

You do so at your own risk. Global names beginning with __ are reserved to the implementation. In other words, there may be no conflict and the above code may compile and work just fine. If the compiler writers prefix their variables with "__" it just makes it easy to avoid conflicts. I'm sure they had reasons for defining different rules for MACROS but I have no idea what those reasons would be. Just follow the guideline in the std and you'll stay out of trouble. Also, avoid writing macros and global variables and functions as much as possible. If you are writing object oriented C++ this issue shouldn't be a big deal.


The std also states the following:

"If the program declares or defines a name in a context where it is reserved, other than as explicitly allowed by this clause,
the behavior is undefined."

You may not get a compiler error if you use a reserved name but the results are undefined. Anyway, the std seems pretty clear to me now that I have read it. Not sure if there is anything left to discuss at this point.

If you really want to use a leading underscore, do this..

Code:

---

int _PREFIX_THEY_WILL_NOT_USE__MyFunctionName();

---

Can I just point out that the double underscore is reserved for anywhere in the name, not just at the start.

Quote:

---

Originally Posted by C++Standard 17.4.3.1.2/1 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.

---

Also, just because the variable you want to name with a leading underscore isn't global doesn't mean that you should do it. You may find that you've hidden an important global variable by doing that. Now, that one could be an interesting debugging exercise.

The simplest rule to remember is "never start a name with an underscore and never use double underscores". It's overkill, but so what? Are leading and double underscores that important?

Quote:

---

Originally Posted by Graham

Can I just point out that the double underscore is reserved for anywhere in the name, not just at the start.



Also, just because the variable you want to name with a leading underscore isn't global doesn't mean that you should do it. You may find that you've hidden an important global variable by doing that. Now, that one could be an interesting debugging exercise.

The simplest rule to remember is "never start a name with an underscore and never use double underscores". It's overkill, but so what? Are leading and double underscores that important?

---

I do not use underscores very often, and when I do it's not at the front. The only time I ever use an underscore in practice at the front, is when I implement _DllMainCRTStartup to bypass the C runtime.