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.

---