Sign in to follow this  
jflanglois

#pragma once and #ifndef BLAHBLAHBLAH_H

Recommended Posts

jflanglois    1020
Hi, This is something that has been bothering me for a while now. When writing header files, I always put #pragma once at the begining (or, if I am compiling to *nix, #ifndef HEADER_H...). I understand what this is used for but my question is: why is this not default behavior in C++? Or, put a different way, in which cases is it useful to not #pragma once a header? Would it not be better to have a "#pragma always" or similar that would explicitly tell the compiler that it can compile the header multiple times? Thanks in advance, jflanglois

Share this post


Link to post
Share on other sites
demonkoryu    980
For example, if your header contains compile time flags (like DEBUG or something), you can set the approbiate flags before #include'ing and you can get different inclusions in multiple places, which wouldn't be possible if it could be included only once.
Most often used by library vendors, but I often use it for debuggin purposes.

Thermo

Share this post


Link to post
Share on other sites
Quote:
Original post by jflanglois
Hi,

This is something that has been bothering me for a while now. When writing header files, I always put #pragma once at the begining (or, if I am compiling to *nix, #ifndef HEADER_H...). I understand what this is used for but my question is: why is this not default behavior in C++? Or, put a different way, in which cases is it useful to not #pragma once a header? Would it not be better to have a "#pragma always" or similar that would explicitly tell the compiler that it can compile the header multiple times?

Thanks in advance,
jflanglois

The primary reason for this, which is subtle, is that the concept of multiple files in a C++ translation unit is somewhat artificial through the preproccessor. By that I mean, once a file is #include'd, you can look at it as a copy-paste of all of the data in the file (unless preprocessor commands such as #ifdef or #ifndef tell it otherwise). Once the file is included, it is just a part of the overall translation unit -- there is no concept of separate files as each file is just one part of a big block of code at that point. Having a #pragma once functionality be standard, let alone default behaviour, would therefore imply that the concept of #include'ing files would have to be slightly redefined.

Share this post


Link to post
Share on other sites
Way Walker    745
Quote:
Original post by Konfusius
For example, if your header contains compile time flags (like DEBUG or something), you can set the approbiate flags before #include'ing and you can get different inclusions in multiple places, which wouldn't be possible if it could be included only once.
Most often used by library vendors, but I often use it for debuggin purposes.


Reminds me... I only have a copy of the C99 draft, but I've heard the following is also true in the official C89 and C99 standards. assert.h is supposed to redefine the assert macro each time it's included. Is this different in C++? The pedant in me was rather upset when I saw:

#ifndef _ASSERT_H_
#define _ASSERT_H_
/* ...defining assert()... */
#endif /* Not _ASSERT_H_ */

in mingw's assert.h :/

Anyway, point is, assert.h is supposed to be an example of what you might do in a header without some sort of include guard.

EDIT: Also, Objective-C has a #import preprocessor directive that is supposed to not include a file more than once, but I don't think my version of mingw does that properly either.

Share this post


Link to post
Share on other sites
jflanglois    1020
Konfusious:
Heh, hadn't thought of that (obviously).

Polymorphic OOP:
OK, that is a good reason why one must do #pragma once. Now, what would be the reason for which the preprocessor was designed in such a way?

All:
Does what Way Walker said apply to C++? That is, does #import "#include" the file only once (not that it would help my cause much, I'm just curious)?

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