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.
#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.
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.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.
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?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
