Talk:Pragma once: Difference between revisions
Cyberbot II (talk | contribs) Notification of altered sources needing review #IABot |
A good practice? |
||
Line 138: | Line 138: | ||
Cheers.—[[User:Cyberbot II|<sup style="color:green;font-family:Courier">cyberbot II</sup>]]<small><sub style="margin-left:-14.9ex;color:green;font-family:Comic Sans MS">[[User talk:Cyberbot II|<span style="color:green">Talk to my owner</span>]]:Online</sub></small> 02:02, 2 April 2016 (UTC) |
Cheers.—[[User:Cyberbot II|<sup style="color:green;font-family:Courier">cyberbot II</sup>]]<small><sub style="margin-left:-14.9ex;color:green;font-family:Comic Sans MS">[[User talk:Cyberbot II|<span style="color:green">Talk to my owner</span>]]:Online</sub></small> 02:02, 2 April 2016 (UTC) |
||
== A good practice ? == |
|||
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 |
|||
[[User:Polarman|Polarman]] ([[User talk:Polarman|talk]]) 18:07, 12 May 2015 (UTC) |
Revision as of 16:08, 12 May 2016
C/C++ Unassessed | ||||||||||
|
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)
#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)
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)
#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)
"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 | ? |
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 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)
- 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)
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)
- 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)
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)
- Nevermind, speed not compilation time SiegeLord (talk) 06:29, 11 October 2008 (UTC)
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)
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)
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 IITalk to my owner:Online 02:02, 2 April 2016 (UTC)
A good practice ?
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