Talk:Pragma once

message: "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)
thread_title: Untitled

message: 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)
replies: text: "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)

text: 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)
replies: text: 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)
thread_title:  Cleanup 

message: 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)
replies: text: 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)
thread_title:  Does this really deserve its own article? 

message: 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)
replies: text: Nevermind, speed not compilation time SiegeLord (talk) 06:29, 11 October 2008 (UTC)
thread_title:  Odd Wording 

message: 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 [] mentions external guards (which seem to improve speed) without explaining what they are. Surement (talk) 18:54, 27 March 2014 (UTC)
thread_title:  Example of implementation 

message: 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)
thread_title:  caveats 

message: Hello fellow Wikipedians,
I have just modified  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 ).
Cheers.—cyberbot IITalk to my owner:Online 02:02, 2 April 2016 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  #pragma once vs include guards? 

message: "#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)
thread_title:  Caveat: Inability to check whether header was actually loaded 

message: 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)
thread_title:  gcc's #pragma once is based on inodes, not files 

message: Its (#pragma once's) implementation is tricky? This must be a first draft. Aboctok (talk) 01:52, 26 December 2020 (UTC)
thread_title:  Cool but vague 

message: 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)
thread_title:  Dead link in reference