Talk:Include guard

I don't think any data that is there on wikipedia should be 'moved' to 'Wikibook', instead it could be copied to wikibook or both can refer to same page but no 'MOVING'. Not all people (including me) like to read books and I found wikipedia to be a very good reference site, if some pages is moved to wikibooks then one will not be able to find a summary information about the same on wikipedia and searching the page on wikibook is a big constraint (its the search result is similar to Google search and then one have to open all links and see which one have better summary and thus defeats the main attaraction of wikipedia)

XWraithanX: Another reason why this shouldn't be moved to the 'Wikibook' is due to the fact that other languages besides C need to have include guards also.

It doesn't belong in the C programming Wikibook because it is not a topic isolated only to C. Other languages implement #include guards (or similar). Cinder6 23:47, 23 October 2006 (UTC)

Also, no one has actually provided a reason why it should be moved. Jibjibjib 23:56, 28 October 2006 (UTC)

I think the guard names (H_<name>) should be renamed to <name>_H since this seems to be the prevailing scheme, at least in my experience. As a back-up, Google Code Search returns about 403,000 results for the query "#ifndef\ [A-Z_]+_H$ lang:c" and only about 300 results for the query "#ifndef\ H_[A-Z_]+$ lang:c". Maybe it would also be good to add something about underscore prefixes (like _NAME_H or __NAME_H) and including pathnames in the guard name (as in _DIRECTORY_FILENAME_H). Vegard 10:05, 25 March 2007 (UTC)

One reason to use H_<name> instead of <name>_H is that the latter easily strays into the namespace that C reserves to the implementation. For example, C reserves all names that begin with E followed by an uppercase letter or a digit, so that most files whose names begin with "e" will infringe on the reserved name space with the <name>_H convention. Pfaffben 23:08, 25 March 2007 (UTC)

In my experience, I've always heard it called the "include shield." Anyone want to verify this and/or include it in the article? Immortal Wowbagger (talk) 07:04, 13 December 2007 (UTC)

Allowed names for #ifndef tokens

I'm not convinced that this quote from the article is true.

_GRANDFATHER_H is prohibited by the C++ standard as it begins with an underscore followed by an upper-case letter

Section 17.4.3.1.2 "Global names", of the C++ standard reads,

Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.¹⁶⁵

where the 165 footnote reads

Such names are also reserved in namespace ::std (17.4.3.1).

I'm not an expert programmer so I could be wrong here. I'm not 100% sure what the standard is saying here but it appears that article statement is either too strong or too weak but not correct as presently worded. It's possible that the wording of the standard implies that an underscore followed by a capital letter is not allowed for tokens but I don't see it. Jason Quinn (talk) 22:58, 26 February 2009 (UTC)

this article belongs in a tutorial, not in an encyclopedia

12:51, 13 September 2010 (UTC) —Preceding unsigned comment added by 210.84.26.229 (talk)

• Correct and proper capitalisation belongs on Wikipedia too :-) This article isn't teaching programming, it's providing information on the prevention of double-inclusion through the use of include guards. It's part of the C/C++ Project, meaning that it's perfectly valid for it to provide language-specific information. I agree it could be reworded a little in a few parts to sound less like a tutorial, however it doesn't deserve to be omitted from the encyclopedia. That kiwi guy (talk) 09:41, 13 June 2014 (UTC)

"idempotence" of a file

I don't think, the reference in the first § to a file being idempotent helps. I know what is meant but it is formally simple not meaningful. How can a file be idempotent? What is the algebraic structure? And what's more, the file could include different things depending on the context (programming language are highly "non-commutative"...) Xlae (talk) 06:05, 6 June 2014 (UTC)