Should I still use #include guards AND #pragma once?

Question

http://en.wikipedia.org/wiki/Pragma_once
Should I still use include guards when all of these compilers support #pragma once?
A lot of responses on stack overflow say to use both for compatibility, but I'm not sure if that still rings true. What compilers today don't support #pragma once?

I am not sure if using both was just a recommendation before it became widley adopted, or if there are still very good reasons to use both methods.
Any examples of when only using #pragma once will cause problems?

Wrongdoer

Remember that older versions of the listed compilers may not support it, so if you're making an open-source program whose source is to be distributed then the pragma may not work. – Dougherty

It's not only about compiler support, but also depends on how complicated the environment is. Do you trust the compiler to know for sure if two files are the same or not, including all netwowrk mounts and symbolic links? – Synonymize

also consider auxiliary tools such as indexers and analyzers. there may not be a full preprocessor or parser behind them, as there is for the compiler. – Gaol

A lot of embedded systems use the old RVCT (or ADS) compilers. I would be very surprised if they support #pragma once. – Maroney

@Maroney RVCT supports #pragma once from (at least) 2.0 – Cunning

Answer 1

It depends on how much portable your program is expected to be.

As long as you are writing a program which is supposed to work with compilers which you know definitely support #prama once, just using #pragma once should suffice. But doing so you restrict your program to set of compilers which support the implementation defined feature.

If you need your program to work on all compilers then you should use #pragma once and include guards both.

In case a compiler does not support #pragma once it will simply ignore it^[Ref#1], in such a case the header guards will serve you the purpose, so nothing wrong in using them both when you are not aware of features supported by your target compilers.

So if you want your program to be 100% portable on different compilers the ideal way is still to use only the include guards. As @CharlesBailey rightly points out since the behavior for #pragma once is implementation defined, the behavior on an unknown compiler might have a detrimental effect on your program.

---

^[Ref#1]
Standard C++03: 16.6 Pragma directive

A preprocessing directive of the form

# pragma pp-tokensopt new-line

causes the implementation to behave in an implementation-defined manner. Any pragma that is not recognized by the implementation is ignored.

Deonnadeonne

If you want your program to be 100.00% portable you need to use include guards but you also need to avoid using #pragma once because the implementation-defined behavior on an unknown compiler might have a detrimental effect on your program. – Ayotte

@CharlesBailey: Agreed. The answer needs modification. I will do that.Thanks for pointing out. – Deonnadeonne

#pragma once will fail if the same file is aliased by two different names at the Operating System / File System level. However, an #include-guard in the file will have the same name, regardless of the file-system reference, and will still work. – Tegument

Answer 2

It's non-standard so if you want to be safe use the include guards

Raeleneraf

Answer 3

As your table shows it is very rare now to encounter a compiler in mainstream use that does not support #pragma once. To keep a code base clean and cheap to maintain requires a constant effort of refactoring. Having to update include guards each time you rename a class or move some code around adds a significant burden to this effort.

So I would say apart from some niche corner cases or for broken build systems #pragma once is in practice safe to rely on. If you care about productivity and code quality using only #pragma once seems the obvious choice.

The exceptions being if you're writing a library that needs to support every compiler under the sun or are unfortunate enough to have to work with one of these rare compilers that does not have this feature.

Teage