This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
"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
#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)
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)
#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
"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)
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)
A note on the ISO committee’s intentions might also be appropriate.
Marshall
14:33, 12 March 2008 (UTC)
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)
- 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.
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)
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)
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)
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:
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).
Cheers.— cyberbot II Talk to my owner:Online 02:02, 2 April 2016 (UTC)
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)
"#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)
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)
Its (#pragma once's) implementation is tricky? This must be a first draft. Aboctok ( talk) 01:52, 26 December 2020 (UTC)
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)
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
"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
#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)
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)
#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
"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)
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)
A note on the ISO committee’s intentions might also be appropriate.
Marshall
14:33, 12 March 2008 (UTC)
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)
- 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.
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)
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)
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)
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:
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).
Cheers.— cyberbot II Talk to my owner:Online 02:02, 2 April 2016 (UTC)
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)
"#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)
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)
Its (#pragma once's) implementation is tricky? This must be a first draft. Aboctok ( talk) 01:52, 26 December 2020 (UTC)
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)