Jump to content

  • Log In with Google      Sign In   
  • Create Account


#pragma once of header guards


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
23 replies to this topic

#1 noatom   Members   -  Reputation: 768

Like
0Likes
Like

Posted 05 February 2013 - 11:34 AM

I'm reading some source code from a book and I just saw that for a header file the author used pragma once,and for another,he just used header guards.
 
I read that pragma once make the code faster and has some other advantages.But should I know anything else? Like when to use header guards or pragma once?
 
Because I read only good things about pragma once and I don't understand why one would use header guards instead of using it.

Sponsor:

#2 Ectara   Crossbones+   -  Reputation: 2765

Like
1Likes
Like

Posted 05 February 2013 - 11:38 AM

#pragma once is non-standard; if you tried to compile your code on a compiler that didn't implement it (or implemented it to do something else entirely), your code would fail. Include guards are the standard-conforming way.



#3 Cornstalks   Crossbones+   -  Reputation: 6966

Like
9Likes
Like

Posted 05 February 2013 - 11:50 AM

Meh, the arguments for and against #pragma once are all kinda moot. The argument against #pragma once is that it's non standard, which is entirely true, but it's still quite portable. The argument for #pragma once is that it's faster, which is kinda false, since common compilers have optimized inclusion guards to effectively have all the speed benefits of #pragma once. My opinion on #pragma once vs inclusion guards: bleh.


[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#4 SiCrane   Moderators   -  Reputation: 9387

Like
9Likes
Like

Posted 05 February 2013 - 11:57 AM

Well one other argument in favor of #pragma once is that you can't accidentally give two header files the same header guard identifier. More the one person posting here has run into the problem of copying and pasting a header guard without remembering to adjust them for the new file.

#5 Ectara   Crossbones+   -  Reputation: 2765

Like
2Likes
Like

Posted 05 February 2013 - 12:04 PM

One somewhat useless benefit of an include guard is that you can test the macro to see if a file has been included. Another equally useless benefit is that  you can undefine the macro to include the file again.

If you do the latter, question your design.

I, personally, always err on the side of standards-compliance, so that's what matters to me. If you are always using a certain compiler that has enormous benefits for #pragma once, and that is what you need, then go for it. Keep in mind, a compiler is allowed to implement #pragma once as syntactic sugar for an include guard with a long enough name to be guaranteed to be unique, and it is allowed to be slower than an include guard. Read the documentation on your compiler to see if it provides huge benefits, or if it provides none at all over include guards, like in GCC which optimizes include guard usage.


Edited by Ectara, 05 February 2013 - 12:05 PM.


#6 NightCreature83   Crossbones+   -  Reputation: 2670

Like
1Likes
Like

Posted 05 February 2013 - 12:47 PM

Well one other argument in favor of #pragma once is that you can't accidentally give two header files the same header guard identifier. More the one person posting here has run into the problem of copying and pasting a header guard without remembering to adjust them for the new file.

Currently the PS3 compiler doesn't support #pragma directives so you still have to be aware of both and for multi-console dev only use header guards.
Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#7 Ameise   Members   -  Reputation: 666

Like
0Likes
Like

Posted 05 February 2013 - 01:44 PM

Well one other argument in favor of #pragma once is that you can't accidentally give two header files the same header guard identifier. More the one person posting here has run into the problem of copying and pasting a header guard without remembering to adjust them for the new file.

Currently the PS3 compiler doesn't support #pragma directives so you still have to be aware of both and for multi-console dev only use header guards.

GCC still does, and they still offer GCC support, as far as I know.



#8 Hodgman   Moderators   -  Reputation: 27590

Like
1Likes
Like

Posted 05 February 2013 - 04:09 PM

Meh, the arguments for and against #pragma once are all kinda moot. The argument against #pragma once is that it's non standard, which is entirely true, but it's still quite portable. The argument for #pragma once is that it's faster, which is kinda false, since common compilers have optimized inclusion guards to effectively have all the speed benefits of #pragma once. My opinion on #pragma once vs inclusion guards: bleh.

This^^ there's no real difference. Just pick one or the other and be consistent.

Well one other argument in favor of #pragma once is that you can't accidentally give two header files the same header guard identifier. More the one person posting here has run into the problem of copying and pasting a header guard without remembering to adjust them for the new file.

This was the only thing that made me choose #pragma once... I've made that mistake before ;)

Currently the PS3 compiler doesn't support #pragma directives so you still have to be aware of both and for multi-console dev only use header guards.

Our PS3 compilers do (including the non-GCC ones)! We use #pragma once in the whole code base (as well as other pragmas too, like optimize off so that you can debug certain sections of code in 'release' builds), which compiles on quite a few consoles. Are you sure you aren't just using certain command line options that are requesting it to be 100% standards compliant?


Edited by Hodgman, 05 February 2013 - 04:22 PM.


#9 SeraphLance   Members   -  Reputation: 1277

Like
1Likes
Like

Posted 05 February 2013 - 04:38 PM

Seriously, use both. The pragma avoids token clashes, and the include guards serve as a fallback on the exceedingly rare case you're compiling on an implementation that doesn't support it.

#10 Hodgman   Moderators   -  Reputation: 27590

Like
0Likes
Like

Posted 05 February 2013 - 04:45 PM

Seriously, use both. The pragma avoids token clashes, and the include guards serve as a fallback on the exceedingly rare case you're compiling on an implementation that doesn't support it.

But, in the fall-back case, the pragma doesn't avoid token clashes... So either there's no point having the pragma in the first place, or, you don't really have a fallback case so there's no point in having the guards?


Edited by Hodgman, 05 February 2013 - 04:48 PM.


#11 Ectara   Crossbones+   -  Reputation: 2765

Like
0Likes
Like

Posted 05 February 2013 - 04:50 PM

Seriously, use both. The pragma avoids token clashes, and the include guards serve as a fallback on the exceedingly rare case you're compiling on an implementation that doesn't support it.

What if the compiler decides to implement it to mean something else? Since it isn't standardized, they are allowed to (no matter how unlikely) implement in a way that may perform something unwanted.

EDIT: My point here was to say use it after researching and proving that #pragma once is worth the risk of non-standard behavior, if you can prove what it will do, and that all compilers you use will implement it in a similar fashion. Saying to use it "just because" is allowed to be problematic, same as relying on alignment rules. Most compilers will try their hardest to allow users' codebases to be compatible with others in this aspect, but not all will. Research first.


Edited by Ectara, 05 February 2013 - 05:43 PM.


#12 L. Spiro   Crossbones+   -  Reputation: 12223

Like
1Likes
Like

Posted 06 February 2013 - 02:16 AM

Seriously, use both.

At first I thought you meant to fix your usage of them (use #pragma once here, use guards there, etc.) which would be absolutely the worst thing to do. Consistency is the best policy.

But you were actually talking about using them both in every single file.
I don’t like this. There is literally no reason to use both in the same file, and it would in fact confuse a lot of people looking at your code.
Firstly, thinking about the headers being a safety net is false hope. You will likely be working on a platform that supports #pragma once (which is why you consider header guards to be fallbacks) which means that the integrity of the header guards has never been tested.
Everyone bumps into that problem with header guards where they reuse the same macros for different headers and you will too. The only difference is that we encounter that on at most 1 file at a time and then quickly realize our error and fix it. If you suddenly have to “fall back” on all of your header guards at once you will suddenly have tons of errors and lots of places that might be tricky to find.


For me, portability is really a concern since I want my engine to go public and I may end up supporting consoles later. So I prefer header guards.
And I, like everyone, have bumped into the problem in which the same macro was used in different files.
my solution however was not to just change over to #pragma once, but to make a tool that not only solves this problem but caters to my desire for consistency.
When I make a new file, I don’t copy-and-paste from an existing file. I hit Ctrl-1 and my script prompts me with a class name, a header guard name, and then makes the shell of a new class, including header guards, for me. It keeps my copyright notice consistent, gives me consistent spacing between the copyright notice, the header guards, the includes, the namespace, and the class declaration, and it ensures I never have this problem with multiply-used header guards.
Another tactic I employed is to include the namespace in the header guard, which has saved me from possible headache in the past.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#13 Bacterius   Crossbones+   -  Reputation: 8157

Like
2Likes
Like

Posted 06 February 2013 - 04:46 AM

You are on a #pragma once enabled compiler:

- you are now typing include guards for nothing since they will be utterly ignored by the compiler

 

You are not on a #pragma once enabled compiler:

- you are now typing the pragma for nothing, and still risk making typos in your include guards

 

Do one or the other, but doing both just doesn't make sense in my opinion, unless I missed something. By doing both you inherit the flaws of both, and none of the benefits.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#14 noatom   Members   -  Reputation: 768

Like
0Likes
Like

Posted 06 February 2013 - 09:52 AM

So far...from what I see,everyone says that the only risk of pragma once is that the compiler you use might not use pragma once to do the same thing as a header guard.But if it does,then it's up to the coder to chose whatever he wants.

 

Thank you all for your answers.



#15 King Mir   Members   -  Reputation: 1910

Like
0Likes
Like

Posted 06 February 2013 - 01:59 PM

It's not likely that #pragma once will do something else. It is possible that #pragma once will not work on some compilers. The only case I would imagine for this is if you're working in embedded systems, with the hardware manufacturer's compiler.



#16 Khatharr   Crossbones+   -  Reputation: 2819

Like
0Likes
Like

Posted 06 February 2013 - 07:40 PM

I'd side with the pragma since it's just easier to use. In cases where it's not supported you can easily write a script to convert to header guards based on the filenames.


void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#17 superman3275   Crossbones+   -  Reputation: 1976

Like
0Likes
Like

Posted 09 February 2013 - 01:21 AM

I generally use Pragma Once because it's implemented roughly the same in almost all major compilers (And I'm not changing Compiler or IDE anytime soon), and it's very easy to use. Rather than worry about naming include guards correctly and bloating my code, I can simply add a #pragma once at the top of my header file.

 

It's more a matter of personal opinion and style than an design changing decision. Both Pragma and Include guards perform the same purpose.


I'm a game programmer and computer science ninja ph34r.png!

Here's Breakout:
Breakout!

Want to ask about Python and / or Pygame? What about HTML5 / CSS3 / JavaScript? What about C++ and / or SFML 2 (and 1.6)? Recruiting for a game development team and need a passionate programmer? Just want to talk about programming? Email me here:

Superman3275@Gmail.com

or Personal-Message me on here smile.png!


#18 Kylotan   Moderators   -  Reputation: 3329

Like
1Likes
Like

Posted 09 February 2013 - 08:17 AM

Amazing how much debate goes into whether to put a couple of lines of text in each file. :) Pretty much a textbook example of bikeshedding right here.

 

I tend to use the explicit header guards, but that's just from a combination of personal inertia and past exposure to people who used #include for unusual purposes that would break with #pragma once. Really, it's not that big a deal - work whatever works for you.



#19 Ectara   Crossbones+   -  Reputation: 2765

Like
0Likes
Like

Posted 09 February 2013 - 09:48 AM

Amazing how much debate goes into whether to put a couple of lines of text in each file. smile.png Pretty much a textbook example of bikeshedding right here.


But should I know anything else? Like when to use header guards or pragma once?

Because I read only good things about pragma once and I don't understand why one would use header guards instead of using it.

I'm just trying to answer the questions directly. I think he should make an educated decision based on his compiler's performance and how it handles the non-standard behavior.

And as far as the easier to type argument, what percentage of the time do you spend on making new header files? It's very easy to type

#ifndef HEADER_H
#define HEADER_H

//Enter code here

#endif

If you are worried about copy-pasting and not changing it, either make a habit of setting up the file properly and double-checking first, or type it manually. I'm just saying, ease of typing something for often less than a minute shouldn't sway the OP's decision.

Also, just noticed that there was a thread on this already:
http://www.gamedev.net/topic/593335-pragma-once-vs-ifndef/



#20 wintertime   Members   -  Reputation: 1601

Like
1Likes
Like

Posted 09 February 2013 - 10:22 AM

I think when you get no advantage from the nonstandard way you should just use the standard way to not uselessly make it unportable, that also applies to this (tiny) issue here. As compilers already optimize the include guards there is no advantage to the pragma.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS