• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
noatom

#pragma once of header guards

23 posts in this topic

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

Share this post


Link to post
Share on other sites

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

1

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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/

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

I think he should make an educated decision based on his compiler's performance and how it handles the non-standard behavior.

The difference in performance is going to be completely negligible until he has an absolutely massive project - and even then the compile times will probably be dominated by 3rd party headers, not his own.

 

As for standard vs non-standard behaviour, it takes less time to discover that than it did for any of us to type out an answer here. If only one of the 2 options is available, the question becomes irrelevant, and if both options are available, the answer is uninteresting - just pick one.

0

Share this post


Link to post
Share on other sites

The difference in performance is going to be completely negligible until he has an absolutely massive project

Or unless he has a compiler which is faster through either method. Not all compilers perform this optimization.


An example for the useless benefit that I mentioned earlier, about testing if a file has been included:

http://www.bobarcher.org/software/include/index.html

In the second example, he describes another pattern of including files, where inside of a header file that includes other header files, he first checks if the header had already been included, to save on time and effort to open the file and preprocess it. This may be defeated by #pragma once, but a compiler is allowed to implement #pragma once to be a naive header guard, too.

As for standard vs non-standard behaviour, it takes less time to discover that than it did for any of us to type out an answer here. If only one of the 2 options is available, the question becomes irrelevant, and if both options are available, the answer is uninteresting - just pick one.


He did ask more than which to use; he asked when to use either, and why would one use header guards over #pragma once. I'm just providing arguments for why people would use header guards.
0

Share this post


Link to post
Share on other sites

Compiler optimisation or not, the difference there is something like 10ms per file per compile. I can guarantee that you'll waste more time trying to optimise this than you will save.

 

I'm not criticising you showing why people choose what they do; I'm just saying this is almost completely irrelevant in the grand scheme of making games and that the original poster should pick whatever is simplest for them.

0

Share this post


Link to post
Share on other sites

If only one of the 2 options is available, the question becomes irrelevant, and if both options are available, the answer is uninteresting - just pick one.

 

mrspock1.jpg

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0