#pragma once of header guards

#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.

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.

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.

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.

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.

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.

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?

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.

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?

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.

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

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.

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.

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.

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.

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.

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.

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.

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/

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.