#pragma once vs #ifndef - Which is better?

[Azaral]

What is the difference between #pragma once and #ifndef guards? Which is better to use and why?

[Lo-X]

#pragma isn't recognize by all compilers. I do not have a list but they tend to include it more and more.

AFAIK there is no differences but #pragma once is definitively more practical

[Laurent]

#pragma once is more efficient because the preprocessor can totally skip the header file (it doesn't have to read its contents). But it is only understood by Visual C++.

So unless you have a huge project and it makes a difference on the compilation time, use #ifdef guards instead.

[Nexus]

Meanwhile, there are a lot of compilers that understand #pragma once. Most modern and relevant compilers support it, at least VC++, g++, clang, Intel.

To be on the safe side, you should still prefer the classical header guards -- #pragma once is not C++ standard, and no compiler is forced to support it.

[FRex]

#pragma once is more efficient (...) But it is only understood by Visual C++.

Seriously Laurent?
http://en.wikipedia.org/wiki/Pragma_once#Portability

Just pick one and use it, it doesn't matter at all. If you move to a compiler that doesn't have pragma once then you can just write a super simple script that will create include guards for you. Include guards are guaranteed to work by standard but might be slower. Some compilers detect if file has include guard and don't reopen it then constantly.
If you are really paranoid about include guards being slower and pragma not being implemented you can use both, unknown pragmas* are ignored and if pragma once fails then include guards do the work.
I use include guards since it doesn't matter in GCC anyway and NetBeans writes them and a creation comment in each header for me automatically.
Also without include guards header files can't prevent each other from including, like glew.h prevents gl.h from being included but that is rarely needed.

*From 16.6.1 in last c++ standard:

A preprocessing directive of the form
# pragma pp-tokensopt new-line
causes the implementation to behave in an implementation-defined manner. The behavior might cause
translation to fail or cause the translator or the resulting program to behave in a non-conforming manner.
Any pragma that is not recognized by the implementation is ignored.

[eXpl0it3r]

My personal preference is:

For libraries, I'll use #ifndef or a mix of both, just to make sure the code is standard conform.
For my own applications/games, I'll use #pragma, because I know which compiler is going to be used and if I make it open source and people have problems with their own compiler, it's not really something I have to fix, since the code was never intended to work for every possible setup.

[Laurent]

Seriously Laurent?

It was true some time ago. Seems like I need an update

[eXpl0it3r]

It was true some time ago. Seems like I need an update

Maybe you were confused, by the fact that GCC once accidentally marked #pragma once as deprecated in their manual.

[Assassin0795]

Not sure if it counts for anything, but what I was taught was to use #ifndef - might have been because we used GCC at the time, though. I use #Pragma once if I know I'm the only one who will be looking/working on the project.

[wintertime]

Keeping the code standards-conformant is always better than not, when there is no huge gain otherwise.
I read a test some time ago that showed some compilers would actually optimize the normal header guards with #ifndef to not open the header file twice. In that case the #pragma extension would get useless anyway, which would explain it getting deprecated.
Btw., completely removing #include statements by forward declaring types in headers may be more useful in reducing compile time.
And maybe in xx years C++ gets modules.

[eXpl0it3r]

Keeping the code standards-conformant is always better than not, when there is no huge gain otherwise.

The "gain" between the two is mostly personal preference, though statistically removing 2/3 of the lines and preventing include guards redefinition (i.e. if two headers use the same guard), is quite significant.

I read a test some time ago that showed some compilers would actually optimize the normal header guards with #ifndef to not open the header file twice. In that case the #pragma extension would get useless anyway

Compilers are always changing so if it was sometime ago, it's likely that it's not true anymore.
Besides of one gets optimized it doesn't automatically render the other useless. It could be optimized as well.

which would explain it getting deprecated.

You didn't read carefully enough, it was by accident.

Btw., completely removing #include statements by forward declaring types in headers may be more useful in reducing compile time.

Forward declaration should always be used where possible, regardless of the include guards, in fact it has nothing to do with it.

[Azaral]

Forward declaration should always be used where possible, regardless of the include guards, in fact it has nothing to do with it.

What do you mean by this?

[Nexus]

What do you mean by this?

If the code doesn't require the definition of a type or function, then it's enough to declare it (and not define it) before it is used. This often means you don't need to include headers.

See also GotW #7

[Azaral]

What do you mean by this?

If the code doesn't require the definition of a type or function, then it's enough to declare it (and not define it) before it is used. This often means you don't need to include headers.

See also GotW #7

Does this just affect compile times or does it also affect actual program performance at run time? I imagine this just applies to compile times.

[Nexus]

Yes, it's just compile times. And it also speeds up tools that perform static code analysis (auto completion, real-time error messages, dependency graphs, doxygen, ...).

(There can be rare cases where it actually affects runtime behavior, such as static/const variables in headers that are not optimized away, symbols that participate in ADL or overload resolution, or macros that change the compilation. But the primary goal is to reduce compile times.)