• 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
Tarviathun

#pragma once

13 posts in this topic

In my computer science class(C++), my professor made a big deal about making sure that headers weren't included more than once. He made everyone define a constant for their headers. The code looked like this:
#ifndef _FOO_H
#define _FOO_H

//header code here

#endif //_FOO_H


Is there any functional/practical difference between this and #pragma once? Or am I being a complete idiot and asking about things of which I know nothing? :)
0

Share this post


Link to post
Share on other sites
AFAIK "#pragma once" belongs to Microsoft specific. Hence it's not recognized by other compilers.

"#ifndef ..." are ANSI, so they are ok.

Cheers.
/def

EDIT: I remember using "#pragma once" in g++. It didn't crash, only said something about it being obsolete... I don't know what it meant by this...
0

Share this post


Link to post
Share on other sites
#pragma once is Microsoft-specific (it is deprecated on GCC), but it also has a different effect than inclusion guards. #pragma once instructs the preprocessor to open and parse the file only once, whereas inclusion guards simply cause an empty text substitution when compositing the compilation units. (MSDN)

Easy on the swear words, eh?
0

Share this post


Link to post
Share on other sites
#pragma once is far more pleasant to use. It has been undeprecated in the more recent versions of gcc (on older versions it works but gives a warning), and may exist in some other compilers as well, but it isn't standard for all c/c++ compilers. Feel free to use it if you're writing specifically for gcc or vc, but be careful if you want your code to work on every compiler under the sun. #ifndef/#define/#endif is much safer in those cases.
0

Share this post


Link to post
Share on other sites
What about using both? Is it necessary to conditionally include the #pragma depending on compiler or will compilers who don't support it just ignore it?

Edit: And what are the defines that can be used to reliably for check for GCC or VC?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by robinei
What about using both? Is it necessary to conditionally include the #pragma depending on compiler or will compilers who don't support it just ignore it?

Edit: And what are the defines that can be used to reliably for check for GCC or VC?


Well, here's how Valve did it:
Quote:
Originally found in Half Life 2 source code file "BaseEntity.h"
#ifndef BASEENTITY_H
#define BASEENTITY_H
#ifdef _WIN32
#pragma once
#endif
//Rest of BaseEntity.h
#endif

which doesn't check for the compiler per se, but it pretty much means Valve says "If we're compiling for Windows, we're using VC. If we're compiling for Linux, etc, we're using something that doesn't support #pragma once"

Use what you are required to use (for the OP that means the #ifndef), or if you have no requirements use what you want.
0

Share this post


Link to post
Share on other sites
Beware, #pragma once doesn't guarantee single inclusion (it could be fooled on VC5 with relative paths, IIRC).
It was meant as an optimization that adds the current include file to a compiler table, so that the file won't be opened again later. Newer compilers are clever enough to do the same when they see standard include guards.
The MS CRT sources show correct use: they have standard include guards and #pragma once.

robinei: Unknown pragmas are ignored but may raise warnings.
__GNUC__ and _MSC_VER identify GCC and VC.

Tarviathun: use the search function! This has already been explained multiple times.
0

Share this post


Link to post
Share on other sites
All #pragma directives are compiler-specific, that's why they're pragmas. There may be some overlap (like GCC supporting MS's 'once' pragma) but the purpose of #pragma is that it's for compiler-specific directives. From this, you can infer that any other directives you see should be compiler-generic.

Pragma Directives
0

Share this post


Link to post
Share on other sites
Thanks all for the help.

Jan, sorry to bug you. I don't mean to keep asking the same things. I did look, but I didn't find anything.

I think for now I'll stick with the non-pragma method. Since I'm attempting to be non-platform/API specific in my current project, I think it'd be good to go the safe route of a well-used standard.
0

Share this post


Link to post
Share on other sites
I use this convention (obviously in addition to include guards):

#if _MSC_VER >= 1200
#pragma once
#endif



Not only do you check to make sure you're using a compiler that supports it, but you're checking to make sure that it's a sufficient version. Not to mention that the platform check is implicit.
0

Share this post


Link to post
Share on other sites
Unknown pragmas are supposed to be ignored by the compiler -- they should never generate an error. So it's not terribly necessary to check that your compiler supports them, but try not to rely on them.
0

Share this post


Link to post
Share on other sites
Tarviathun: sure, no one means ill. If you looked, all is well :)

Zipster: IIRC C99 says undefined macros in #if evaluate to 0, but ICC warns you about it. It's a little bit safer to write #if defined(x) && x > 1200.
0

Share this post


Link to post
Share on other sites
Of all the things to worry about, I'd put that at the bottom of the list [smile]
But fine, you win you sexy man you. Finally I get to use "Replace in Files".
0

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