4

This answer points to the reference material stating that you should not use two underscores followed by a capital letter.

Then there is this comment to this question, the first by @metal, that says you also cannot use such a name when creating include guards.

However, I'm curious then why Xcode does exactly that when it automatically creates include guards for new C++ files:

#ifndef __DataSource__File__
#define __DataSource__File__

#include <iostream>

#endif

This is the standard biolerplate that Xcode places at the top of a new C++ file; in this case, the project is named "DataSource". If the name of the project started with a digit, then Xcode would replace this digit with a third underscore.

If it's illegal for a user to write this, then isn't it illegal for Xcode to write this?

Community
  • 1
  • 1
johnbakers
  • 24,158
  • 24
  • 130
  • 258
  • 1
    "Shouldn't" doesn't mean "illegal". And the "standards" for include guards have been all over the place in the past 40-odd years. – Hot Licks Apr 25 '13 at 01:11
  • The fact remains that if the standard refers to these as "reserved identifiers" then using them is a bad idea. So why would a major IDE do it? – johnbakers Apr 25 '13 at 01:14
  • 1
    @SebbyJohanns: Why wouldn't it? Software developers are only human, even at Apple, and humans are infamous for their fallibility. – Mike Seymour Apr 25 '13 at 01:39
  • Objective-C is based on C, not C++. It's standards go back before C++. – Hot Licks Apr 25 '13 at 02:32
  • @HotLicks I am not referring at all to Objective C files. I am talking about raw C++ files. Xcode supports many languages. – johnbakers Apr 25 '13 at 02:42
  • Right, but the conventions that Xcode uses are old ones, from when Objective-C was first designed. – Hot Licks Apr 25 '13 at 11:16
  • @HotLicks Include guards are not a convention in Objective-C at all (in fact its `import` directive makes them unnecessary), so I'd expect they were introduced whenever C++ support was introduced. – johnbakers Apr 25 '13 at 11:17

2 Answers2

4

If it's illegal for a user to write this, then isn't it illegal for Xcode to write this?

Indeed, although "illegal" is perhaps rather a strong word. If that is the default behaviour, then whoever configured it to generate dodgy include guards didn't know that you shouldn't do that. Sadly, not every software developer (even those making development tools) has complete knowledge of the language and tools they use.

A great many people like to decorate their include guards with weird patterns of underscores, even though they shouldn't. Presumably, they see it done in standard library headers (as it should be, since that's the sort of thing that such names are reserved for) and assume that they should do the same for some reason.

Mike Seymour
  • 249,747
  • 28
  • 448
  • 644
3

Xcode is wrong. Names that begin with an underscore followed by a capital letter and names that contain two consecutive underscores are reserved to the implementation. Always have been.

Pete Becker
  • 74,985
  • 8
  • 76
  • 165
  • But Objective-C/Xcode *is* "the implementation" -- if they want to do it that way they can. – Hot Licks Apr 25 '13 at 02:34
  • @HotLicks absolutely incorrect. Xcode is not synonymous with Objective-C. You can build software in many languages with Xcode and this question is specifically talking about how it handles C++. In fact this issue does not appear when creating files from other languages in Xcode. – johnbakers Apr 25 '13 at 02:46
  • 1
    Pedantic bit, Macro symbols are not actually bound by this restriction. Section 16.8-4 just indicates that predefined macros must follow this restrction. Section 17.6.4.3.2 says that global names are bound by this restriction, but that does not include macros. Though combined with 17.6.4.3.1 (macros names can't overlap globals) it may mean they are effectively disallowed. – edA-qa mort-ora-y Apr 25 '13 at 06:52
  • @edA-qamort-ora-y: I think you missed the part of 17.6.4.3.2 saying that names like these (containing a double underscore) are reserved *for any use*, i.e. including macros. And as you say, even if it were the less restricted type of name (beginning with a single underscore), defining a macro can prevent its reserved use as a name in the global namespace, so is not allowed unless you're very careful where you define it. – Mike Seymour Apr 25 '13 at 10:55
  • @SebbyJohanns - Because other languages don't have the same restrictions (or the same stupid need to have include guards). – Hot Licks Apr 25 '13 at 11:19
  • @HotLicks - no, Xcode is not the implementation. The implementation is the compiler and runtime library. The language definition does **not** talk about IDEs, text editors, or your uncle Harry. One of the reasons for this rule is that standard library implementors need to use names that will not step on user-defined names. If you use names that are reserved to the implementation you risk screwing up the standard library headers or your own code. – Pete Becker Apr 25 '13 at 11:30
  • I said *Objective-C/Xcode*. Together they define an "implementation", and, in the vast majority of cases, C++ is just a "guest" there. – Hot Licks Apr 25 '13 at 11:51
  • @HotLicks - the C++ language definition does not know or care about Xcode. It defines what constitutes valid C++ code, and what a conforming **compiler** and **runtime library** (i.e., "an implementation") must do. This is **not** valid C++ code, and misreading "implementation" to mean "whatever tool I happen to be using at the moment" does not change that. – Pete Becker Apr 25 '13 at 11:54
  • @HotLicks suggesting that C++ is just a "guest" on Xcode is quite a naive statement. Educate yourself. – johnbakers Apr 25 '13 at 13:18
  • If you throw together C (pick an old version, just for fun), C++, FORTRAN, and Pascal, you're not going to find any way to get them to work together without breaking someone's rule. Throw in Objective-C and it's a real free-for-all. In the case of C++, it was added on to the Objective-C/Xcode environment well after that environment was established, and the "standards" (such as they are) that it follows are primarily what worked originally with C and doesn't break C++. Live with it. – Hot Licks Apr 25 '13 at 16:03
  • 3
    @HotLicks - I don't understand why you're so aggressively defending wrong behavior. Is there a good reason why Xcode does this? – Pete Becker Apr 25 '13 at 16:10
  • Xcode is a full-featured C++ IDE with standard modern compilers, and even some of Apple's own iOS frameworks are implemented in C++. To suggest it was somewhat of an afterthought is just naive. – johnbakers Apr 25 '13 at 16:19
  • If you're so hot about it, file a bug report. – Hot Licks Apr 25 '13 at 16:36