Talk:Pragma once

Untitled

"It is a Microsoft specific C/C++ preprocessor directive."

I don't think it is Microsoft specific, it is used by CodeWarrior also, and there is support in GCC for Darwin (probably for combatibility with CodeWarrior which was predominant before OSX/gcc on Macintosh) --unsigned comment

Not only that, but the only info on its origin I can find suggests that it was first recognised by GCC 1.35, or so sayeth Ian Lance Taylor. Of course, GCC went on to deprecate its baby, but it's currently fully supported again. Just considered non-portable & thus disliked. Does anyone have any information to the contrary? If not, I think I'll alter the article to say so; I'll leave it a while in case someone does have more information than I. —SirPavlova 19:44, 1 January 2007 (UTC)[reply]

#pragma once has worked in GCC since it became un-deprecated in 3.4. It also can improve build speeds on certain compilers even more than regular internal inclusion guards which should probably be mentioned in the article. Also, I don't know why the bulk of this article is spent explaining _MSC_VER. It should just recieve a passing mention.--66.93.225.126 23:44, 2 June 2006 (UTC)[reply]

Cleanup

Attempted to clean up article. Jafet

It still needs a complete rework. The pragma "usually" does something? Does the compiler flip a coin? I know what it means, but only because I already knew what it means.

tidied up just a little to deal with the 'usually' language OMatthews 07:35, 10 October 2006 (UTC)[reply]

#pragma once is deprecated by the GCC documentation.[1]

When you go to link you'll see that it incorrect :) GCC documentations said that you shouldn't rely on pragma once in portable programs, but it isn't deprecated

"11.3 Obsolete Features CPP has a number of features which are present mainly for compatibility with older programs. We discourage their use in new code. In some cases, we plan to remove the feature in a future version of GCC." True, it doesn't say exactly which features are slated for removal, versus merely discouraged, but "deprecated" is shorter than "listed as obsolete". :) But you're right; I'll change the wording to "listed as obsolete" until someone can find a definitive source. --Quuxplusone 06:39, 17 December 2006 (UTC)[reply]

"the GCC documentation lists #pragma once as an "obsolete" feature." The reference cited, and I have not been able to find one more definitive, warns that #pragma once is non-portable, but nowhere does it say that it is obsolete. In fact it is referred to favorably compared to #import. I changed the wording to reflect this. Gauss256 (talk) 08:18, 7 February 2008 (UTC)[reply]

While cleaning this article up, would it be well served if a compiler usage table was given? E.g.

Compiler	#pragma once
C++ Builder	?
C++ Compiler	No
Comeau C/C++	No
Digital Mars	Yes
GCC	No
Intel C++ Compiler	Yes
Local C compiler	?
MULTI	Yes
Open Watcom	Yes
PathScale	No
PGI Workstation	Yes
Portable C Compiler	No
ProDev WorkShop	Yes
RealView C/C++ Compiler (armcc)	?
SAS/C	?
Sun Studio	?
TenDRA	?
Tiny C Compiler	?
Visual Studio	Yes
VisualAge	?
XL C/C++	?
AMPC	?
Nwcc	?
VectorC	?

Note: The above table is an example only. No data should be taken from it. Additional data might include specific versions; if it handles links correctly; and other relevant information. Marshall 14:33, 12 March 2008 (UTC)[reply]

A note on the ISO committee’s intentions might also be appropriate. Marshall 14:33, 12 March 2008 (UTC)[reply]

I am working with a C++ code written with Visual C++ now migrating to gcc and I really need to know is if pragma once works with gcc (even though deprecated). The discussion of pragma once in gcc in this article is not up-to date and should be rectified. I am using gcc version 4.3.3 and it warns me about pragma once being deprecated. The GNU C++ Manual also warns: #pragma once is now obsolete and should not be used at all. Ben ^T/_C 12:08, 26 November 2009 (UTC)[reply]

Update. The manual of gcc 4.3.4 about pragma once: [...] Another way to prevent a header file from being included more than once is with the ‘#pragma once’ directive. If ‘#pragma once’ is seen when scanning a header file, that file will never be read again, no matter what. ‘#pragma once’ does not have the problems that ‘#import’ does, but it is not recognized by all preprocessors, so you cannot rely on it in a portable program. I conclude: gcc processes pragma once, but RMA does not recommend it (because it's not standard). Ben ^T/_C 14:30, 27 November 2009 (UTC)[reply]

Does this really deserve its own article?

I guess I'm suggesting a merger between this article and include guard. They might not be exactly the same this, but their functionality is very similar and both articles are very short. I don't feel enough unique information is here. It even depends on the include guards article for its example! If they were in the same article, we could simply say "the above example could be rewritten as..."

I feel the advantages/disadvantages section would make more sense in an article that contained the information of both.

Just for pure clarity, my suggestion is: Add a section for #pragma once in include guard, including advantages and disadvantages. Replace this entire page with a redirect to the #pragma once section in include guard.
Posted by: SoC (talk) -- Posted at:: 08:31, 21 August 2008 (UTC)[reply]

- terrible idea. this is the first hit on google for "# pragma once". it concisely desribes what it means in a few paragraphs. thus this page is doing it's job perfectly. don't try to fix what isn't broken please.

But I do think some thing's broken! This article relies on another article! If this should not merged, I move the example be copied and pasted from the other article. Although users may have to click on another article when they don't understand something, they should never be forced to. Posted by: SoC (talk) -- Posted at:: 05:49, 10 September 2008 (UTC)[reply]

Odd Wording

From the article: "Using #pragma once instead of include guards will typically increase compilation speed since it is a higher-level mechanism; the compiler itself can compare filenames or inodes without having to invoke the C preprocessor to scan the header for #ifndef and #endif."

The sentence makes no sense, and I heard otherwise on some websites... can someone clarify it? SiegeLord (talk) 17:46, 30 August 2008 (UTC)[reply]

Nevermind, speed not compilation time SiegeLord (talk) 06:29, 11 October 2008 (UTC)[reply]

Example of implementation

Since the article claims improved compilation speeds in some cases, it would be nice to see an example of how #pragma once is implemented. Further, the first link [[2]] mentions external guards (which seem to improve speed) without explaining what they are. Surement (talk) 18:54, 27 March 2014 (UTC)[reply]

caveats

For any modern, project based build system with pattern aligned file system layout (eclipse w/o linked resource), maven/gradle/etc, there is zero links/path duplications, so pragma once should be perfectly safe. 199.46.198.231 (talk) 17:41, 27 August 2015 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Pragma once. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Corrected formatting/usage for http://www.gamesfromwithin.com/articles/0501/000067.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 02:02, 2 April 2016 (UTC)[reply]

#pragma once vs include guards?

Is it a good practice to write to be compatible with a compiler that ignore a #pragma statement?

 #ifndef MY_FILE_H
 #define MY_FILE_H
 #pragma once
  
 ... code here
  
 #endif

Réf: stackoverflow.com > pragma-once-vs-include-guards

Polarman (talk) 18:07, 12 May 2015 (UTC)[reply]

Caveat: Inability to check whether header was actually loaded

"#pragma once", doesn't actually give a programmer the ability to check whether certain header was loaded. Say we have two separate implementations of _something_ in two separate sources, without header guards you can't distinguish between the two at compile time, unless you do separate "feature" define which somewhat defeats the purpose and takes away from advantages. There are of course various ways to deal with this, but it's an example of caveat not mentioned in the article. 86.49.254.86 (talk) 14:19, 8 June 2018 (UTC)[reply]

gcc's #pragma once is based on inodes, not files

gcc (which i'm guessing is by far the most popular compiler on the list, followed by Clang)'s "pragma once" doesn't care about filepaths, it cares about inodes. can test this by making a lol.c with

#include "lol2.c"
#include "lol3.c"
#include "lol4.c"
int main(){}

then making a lol2.c with

#pragma once
void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes(){}

then running

$ ln -s lol2.c lol3.c
$ ln -s lol3.c lol4.c
$ gcc lol.c
$ echo $?
0
$ ./a.out
$

.. no errors. no collision. because all 3 files had the same inode, and gcc's "#pragma once" works on inodes. now try giving each file an unique inode:

$ rm lol3.c lol4.c
$ cp lol2.c lol3.c
$ cp lol2.c lol4.c
$ gcc lol.c
In file included from lol.c:2:
lol3.c:2:6: error: redefinition of ‘void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes()’
    2 | void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes(){}
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from lol.c:1:
lol2.c:2:6: note: ‘void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes()’ previously defined here
    2 | void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes(){}
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from lol.c:3:
lol4.c:2:6: error: redefinition of ‘void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes()’
    2 | void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes(){}
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from lol.c:1:
lol2.c:2:6: note: ‘void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes()’ previously defined here
    2 | void this_function_name_will_collide_if_pragma_once_works_on_filepaths_instead_of_inodes(){}
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

gcc's "pragma once" doesn't care about filepaths, it cares about inodes.

80.203.132.70 (talk) 19:10, 9 October 2020 (UTC)[reply]

Cool but vague

Its (#pragma once's) implementation is tricky? This must be a first draft. Aboctok (talk) 01:52, 26 December 2020 (UTC)[reply]

Dead link in reference

the reference number #9 in the main article is a deadlink, I want to replace it with a live link and with a reliable source as it comes to pragma so that people could find the right info here. Elvismartin1515 (talk) 09:28, 2 March 2023 (UTC)[reply]