Template (.tpp) file include guards

When writing templated classes, I like to move the implementation into a different file (myclass.tpp) and include it at the bottom of the main header (myclass.hpp).

My Question is: do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Example code:

myclass.hpp

#ifndef MYCLASS_HPP

#define MYCLASS_HPP



template<typename T>

class MyClass

{

public:

    T foo(T obj);

};



//include template implemetation

#include "myclass.tpp"



#endif

myclass.tpp

#ifndef MYCLASS_TPP //needed?

#define MYCLASS_TPP //needed?



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif //needed?

edited Jan 25 at 12:10

YSC

25.2k557112

asked Jan 25 at 9:54

dave

613111

They should be present in all header files that are not supposed to be inlined multiple times. If myclass.tpp is supposed to be included only in myclass.hpp then it would make sense to add additional guards.

– VTT
Jan 25 at 9:56

6

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

– StoryTeller
Jan 25 at 10:01

1

would your .tpp be included by others? if not (I guess), why guard over it?

– apple apple
Jan 25 at 10:16

1

otherwise this may be used to optionally include feature .tpps (by user), then the guard is needed (but I'd say it'd be better to use .hpp)

– apple apple
Jan 25 at 10:19

plus I don't think anyone would directly include .tpp, just like .cpp

– apple apple
Jan 25 at 10:23

|
show 2 more comments

When writing templated classes, I like to move the implementation into a different file (myclass.tpp) and include it at the bottom of the main header (myclass.hpp).

My Question is: do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Example code:

myclass.hpp

#ifndef MYCLASS_HPP

#define MYCLASS_HPP



template<typename T>

class MyClass

{

public:

    T foo(T obj);

};



//include template implemetation

#include "myclass.tpp"



#endif

myclass.tpp

#ifndef MYCLASS_TPP //needed?

#define MYCLASS_TPP //needed?



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif //needed?

edited Jan 25 at 12:10

YSC

25.2k557112

asked Jan 25 at 9:54

dave

613111

They should be present in all header files that are not supposed to be inlined multiple times. If myclass.tpp is supposed to be included only in myclass.hpp then it would make sense to add additional guards.

– VTT
Jan 25 at 9:56

6

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

– StoryTeller
Jan 25 at 10:01

1

would your .tpp be included by others? if not (I guess), why guard over it?

– apple apple
Jan 25 at 10:16

1

otherwise this may be used to optionally include feature .tpps (by user), then the guard is needed (but I'd say it'd be better to use .hpp)

– apple apple
Jan 25 at 10:19

plus I don't think anyone would directly include .tpp, just like .cpp

– apple apple
Jan 25 at 10:23

|
show 2 more comments

When writing templated classes, I like to move the implementation into a different file (myclass.tpp) and include it at the bottom of the main header (myclass.hpp).

My Question is: do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Example code:

myclass.hpp

#ifndef MYCLASS_HPP

#define MYCLASS_HPP



template<typename T>

class MyClass

{

public:

    T foo(T obj);

};



//include template implemetation

#include "myclass.tpp"



#endif

myclass.tpp

#ifndef MYCLASS_TPP //needed?

#define MYCLASS_TPP //needed?



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif //needed?

edited Jan 25 at 12:10

YSC

25.2k557112

asked Jan 25 at 9:54

dave

613111

When writing templated classes, I like to move the implementation into a different file (myclass.tpp) and include it at the bottom of the main header (myclass.hpp).

My Question is: do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Example code:

myclass.hpp

#ifndef MYCLASS_HPP

#define MYCLASS_HPP



template<typename T>

class MyClass

{

public:

    T foo(T obj);

};



//include template implemetation

#include "myclass.tpp"



#endif

myclass.tpp

#ifndef MYCLASS_TPP //needed?

#define MYCLASS_TPP //needed?



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif //needed?

c++ templates include-guards

edited Jan 25 at 12:10

YSC

25.2k557112

asked Jan 25 at 9:54

dave

613111

edited Jan 25 at 12:10

YSC

25.2k557112

asked Jan 25 at 9:54

dave

613111

edited Jan 25 at 12:10

YSC

25.2k557112

edited Jan 25 at 12:10

YSC

25.2k557112

edited Jan 25 at 12:10

YSC

25.2k557112

asked Jan 25 at 9:54

dave

613111

asked Jan 25 at 9:54

dave

613111

asked Jan 25 at 9:54

dave

613111

They should be present in all header files that are not supposed to be inlined multiple times. If myclass.tpp is supposed to be included only in myclass.hpp then it would make sense to add additional guards.

– VTT
Jan 25 at 9:56

6

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

– StoryTeller
Jan 25 at 10:01

1

would your .tpp be included by others? if not (I guess), why guard over it?

– apple apple
Jan 25 at 10:16

1

otherwise this may be used to optionally include feature .tpps (by user), then the guard is needed (but I'd say it'd be better to use .hpp)

– apple apple
Jan 25 at 10:19

plus I don't think anyone would directly include .tpp, just like .cpp

– apple apple
Jan 25 at 10:23

|
show 2 more comments

They should be present in all header files that are not supposed to be inlined multiple times. If myclass.tpp is supposed to be included only in myclass.hpp then it would make sense to add additional guards.

– VTT
Jan 25 at 9:56

6

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

– StoryTeller
Jan 25 at 10:01

1

would your .tpp be included by others? if not (I guess), why guard over it?

– apple apple
Jan 25 at 10:16

1

otherwise this may be used to optionally include feature .tpps (by user), then the guard is needed (but I'd say it'd be better to use .hpp)

– apple apple
Jan 25 at 10:19

plus I don't think anyone would directly include .tpp, just like .cpp

– apple apple
Jan 25 at 10:23

They should be present in all header files that are not supposed to be inlined multiple times. If myclass.tpp is supposed to be included only in myclass.hpp then it would make sense to add additional guards.

– VTT
Jan 25 at 9:56

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

– StoryTeller
Jan 25 at 10:01

would your .tpp be included by others? if not (I guess), why guard over it?

– apple apple
Jan 25 at 10:16

otherwise this may be used to optionally include feature .tpps (by user), then the guard is needed (but I'd say it'd be better to use .hpp)

– apple apple
Jan 25 at 10:19

plus I don't think anyone would directly include .tpp, just like .cpp

– apple apple
Jan 25 at 10:23

|
show 2 more comments

2 Answers
2

active

oldest

votes

Do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Include guards are never needed: they're just terribly useful, cheap, non-disruptive and expected. So Yes, you should protect both files with header guards:

Terribly useful: they allow you to declare a dependency from multiple files without keeping track of which files have already be included.

Cheap: this is just some precompilation tokens.

Non-disruptive: they fit well with most use-cases of #include (I've had a colleague who didn't know how to write macros so he #included implementation files *facepalm*).

Expected: developers know what they are and barely notice them; on the contrary a header file missing include guards wakes us up and adds to the global wtf/line counter.

I take the opportunity to highlight the comment from StoryTeller:

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

Which will translate to:

#ifndef MYCLASS_TPP

#define MYCLASS_TPP



#ifndef MYCLASS_HPP

#error __FILE__ should only be included from myclass.hpp.

#endif // MYCLASS_HPP



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif // MYCLASS_TPP

Notice: if a translation unit first #include <myclass.hpp> and then #include <myclass.tpp>, no error is fired and everything is fine.

edited Jan 25 at 11:07

Baum mit Augen♦

41.5k12120156

answered Jan 25 at 10:20

YSC

25.2k557112

1

Nice! Although if I prevent including the .tpp file directly by throwing this error, is the MYCLASS_TPP define not reduntant?

– dave
Jan 25 at 10:24

2

@dave No. If your user first includes myclass.hpp and then myclass.tpp, the error won't fire.

– Max Langhof
Jan 25 at 10:26

1

I disagree with the sentence include guards are never needed. Suppose an header A.hpp needs to include another header B.hpp (because, for instance, it uses the definitions found in B.hpp), and suppose you write a code which needs both A.hpp and B.hpp. Unless you inspect the code of A.hpp, you would not know that #include "B.hpp" is not needed. Then, you would include both A.hpp and B.hpp, resulting in a double include of B.hpp. The include guard prevents this.

– francesco
Jan 25 at 10:43

1

@francesco There's always a way around, but its a bad way no-one should take: include guards are not needed: just terribly useful.

– YSC
Jan 25 at 10:44

2

@francesco The hair-splitting answer would be "#pragma once can also do it in basically any compiler".

– Max Langhof
Jan 25 at 10:45

|
show 4 more comments

Just use pragma once in all headers file. The compiler will ensure your file will be included only once. The compiler may only fail to recognize in very unreasonable condition: someone structure its include directories using hard-link. Who does this? If someone cannot find a unique name for its file, why would he be more skilled to find a unique name for each include guard for all the header files?

On the other hand, include guard may be broken because the name of the macro will not be that unique, because of a copy/paste, or a header file created by first copying an other, etc...

How are chosen the unique macro name: <project name>_<filename>? How could it be more unique than a uniqueness based on the entire root directory structure?

So in the end, one should consider when choosing between include guard or pragma once, the cost of the job that is necessary to ensure uniqueness:

1 - For pragma once you only have to ensure that the directory structured of your system is not messed-out thanks to hard links.

2 - For include guard for each file on your system you should ensure that the macro name is unique.

I mean as a manager, evaluating the cost of this job and the failure risk does let only one option. Include guard are used only when no evaluation is performed: it is a non decision.

edited Jan 25 at 13:04

answered Jan 25 at 11:10

Oliv

9,4021957

2

I agree: if you control your build environment (e.g. this is a proprietary project) there's no reason not to use #pragma once. If you're writing an open source library you'd like to be used on obscures build environments (embedded, old systems, etc.), maybe just stick to include guards.

– YSC
Jan 25 at 12:09

@YSC Not writing but maintaining an old library. For a new library, that may be added to an old system, you just specify that this library should not be hardlinked and that all. There are no reason to make every body pay for an ancient practice that might still be in use by a number of people that can be count on the one hand. It is like asking million of coder to loose their time to improbably increase the productivity of 2 or 3 system administrator.

– Oliv
Jan 25 at 12:21

I was thinking about compilers too old/obscure to know #pragma once ;) But yes.

– YSC
Jan 25 at 12:22

I believe they both have their uses. Years ago not all compilers supported #pragma once, so many were forced to use header guards, however, most compilers today should fully support #pragma once without issue. Typically if I have a single header file that is a class' declaration I'll use header guards with the name of the class file where that class file is the name of the class. If I have a header file that has a bunch of macros, defines, constants and just stand alone function declarations, then I'll more than likely use #pragma once. This is just my preference.

– Francis Cugler
Jan 25 at 14:32

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54362798%2ftemplate-tpp-file-include-guards%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

Do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Include guards are never needed: they're just terribly useful, cheap, non-disruptive and expected. So Yes, you should protect both files with header guards:

Terribly useful: they allow you to declare a dependency from multiple files without keeping track of which files have already be included.

Cheap: this is just some precompilation tokens.

Non-disruptive: they fit well with most use-cases of #include (I've had a colleague who didn't know how to write macros so he #included implementation files *facepalm*).

Expected: developers know what they are and barely notice them; on the contrary a header file missing include guards wakes us up and adds to the global wtf/line counter.

I take the opportunity to highlight the comment from StoryTeller:

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

Which will translate to:

#ifndef MYCLASS_TPP

#define MYCLASS_TPP



#ifndef MYCLASS_HPP

#error __FILE__ should only be included from myclass.hpp.

#endif // MYCLASS_HPP



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif // MYCLASS_TPP

Notice: if a translation unit first #include <myclass.hpp> and then #include <myclass.tpp>, no error is fired and everything is fine.

edited Jan 25 at 11:07

Baum mit Augen♦

41.5k12120156

answered Jan 25 at 10:20

YSC

25.2k557112

1

Nice! Although if I prevent including the .tpp file directly by throwing this error, is the MYCLASS_TPP define not reduntant?

– dave
Jan 25 at 10:24

2

@dave No. If your user first includes myclass.hpp and then myclass.tpp, the error won't fire.

– Max Langhof
Jan 25 at 10:26

1

I disagree with the sentence include guards are never needed. Suppose an header A.hpp needs to include another header B.hpp (because, for instance, it uses the definitions found in B.hpp), and suppose you write a code which needs both A.hpp and B.hpp. Unless you inspect the code of A.hpp, you would not know that #include "B.hpp" is not needed. Then, you would include both A.hpp and B.hpp, resulting in a double include of B.hpp. The include guard prevents this.

– francesco
Jan 25 at 10:43

1

@francesco There's always a way around, but its a bad way no-one should take: include guards are not needed: just terribly useful.

– YSC
Jan 25 at 10:44

2

@francesco The hair-splitting answer would be "#pragma once can also do it in basically any compiler".

– Max Langhof
Jan 25 at 10:45

|
show 4 more comments

Do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Include guards are never needed: they're just terribly useful, cheap, non-disruptive and expected. So Yes, you should protect both files with header guards:

Terribly useful: they allow you to declare a dependency from multiple files without keeping track of which files have already be included.

Cheap: this is just some precompilation tokens.

Non-disruptive: they fit well with most use-cases of #include (I've had a colleague who didn't know how to write macros so he #included implementation files *facepalm*).

Expected: developers know what they are and barely notice them; on the contrary a header file missing include guards wakes us up and adds to the global wtf/line counter.

I take the opportunity to highlight the comment from StoryTeller:

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

Which will translate to:

#ifndef MYCLASS_TPP

#define MYCLASS_TPP



#ifndef MYCLASS_HPP

#error __FILE__ should only be included from myclass.hpp.

#endif // MYCLASS_HPP



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif // MYCLASS_TPP

Notice: if a translation unit first #include <myclass.hpp> and then #include <myclass.tpp>, no error is fired and everything is fine.

edited Jan 25 at 11:07

Baum mit Augen♦

41.5k12120156

answered Jan 25 at 10:20

YSC

25.2k557112

1

Nice! Although if I prevent including the .tpp file directly by throwing this error, is the MYCLASS_TPP define not reduntant?

– dave
Jan 25 at 10:24

2

@dave No. If your user first includes myclass.hpp and then myclass.tpp, the error won't fire.

– Max Langhof
Jan 25 at 10:26

1

I disagree with the sentence include guards are never needed. Suppose an header A.hpp needs to include another header B.hpp (because, for instance, it uses the definitions found in B.hpp), and suppose you write a code which needs both A.hpp and B.hpp. Unless you inspect the code of A.hpp, you would not know that #include "B.hpp" is not needed. Then, you would include both A.hpp and B.hpp, resulting in a double include of B.hpp. The include guard prevents this.

– francesco
Jan 25 at 10:43

1

@francesco There's always a way around, but its a bad way no-one should take: include guards are not needed: just terribly useful.

– YSC
Jan 25 at 10:44

2

@francesco The hair-splitting answer would be "#pragma once can also do it in basically any compiler".

– Max Langhof
Jan 25 at 10:45

|
show 4 more comments

Do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Include guards are never needed: they're just terribly useful, cheap, non-disruptive and expected. So Yes, you should protect both files with header guards:

Terribly useful: they allow you to declare a dependency from multiple files without keeping track of which files have already be included.

Cheap: this is just some precompilation tokens.

Non-disruptive: they fit well with most use-cases of #include (I've had a colleague who didn't know how to write macros so he #included implementation files *facepalm*).

Expected: developers know what they are and barely notice them; on the contrary a header file missing include guards wakes us up and adds to the global wtf/line counter.

I take the opportunity to highlight the comment from StoryTeller:

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

Which will translate to:

#ifndef MYCLASS_TPP

#define MYCLASS_TPP



#ifndef MYCLASS_HPP

#error __FILE__ should only be included from myclass.hpp.

#endif // MYCLASS_HPP



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif // MYCLASS_TPP

Notice: if a translation unit first #include <myclass.hpp> and then #include <myclass.tpp>, no error is fired and everything is fine.

edited Jan 25 at 11:07

Baum mit Augen♦

41.5k12120156

answered Jan 25 at 10:20

YSC

25.2k557112

Do I need include guards in the .tpp file or is it sufficient to have them in the .hpp file?

Include guards are never needed: they're just terribly useful, cheap, non-disruptive and expected. So Yes, you should protect both files with header guards:

Terribly useful: they allow you to declare a dependency from multiple files without keeping track of which files have already be included.

Cheap: this is just some precompilation tokens.

Non-disruptive: they fit well with most use-cases of #include (I've had a colleague who didn't know how to write macros so he #included implementation files *facepalm*).

Expected: developers know what they are and barely notice them; on the contrary a header file missing include guards wakes us up and adds to the global wtf/line counter.

I take the opportunity to highlight the comment from StoryTeller:

I'd go a step further and add a descriptive #error directive if the hpp guard is not defined. Just to offer a little protection from people including the tpp first.

Which will translate to:

#ifndef MYCLASS_TPP

#define MYCLASS_TPP



#ifndef MYCLASS_HPP

#error __FILE__ should only be included from myclass.hpp.

#endif // MYCLASS_HPP



template<typename T>

T MyClass<T>::foo(T obj)

{

    return obj;

}



#endif // MYCLASS_TPP

Notice: if a translation unit first #include <myclass.hpp> and then #include <myclass.tpp>, no error is fired and everything is fine.

edited Jan 25 at 11:07

Baum mit Augen♦

41.5k12120156

answered Jan 25 at 10:20

YSC

25.2k557112

edited Jan 25 at 11:07

Baum mit Augen♦

41.5k12120156

edited Jan 25 at 11:07

Baum mit Augen♦

41.5k12120156

edited Jan 25 at 11:07

Baum mit Augen♦

41.5k12120156

answered Jan 25 at 10:20

YSC

25.2k557112

answered Jan 25 at 10:20

YSC

25.2k557112

answered Jan 25 at 10:20

YSC

25.2k557112

1

Nice! Although if I prevent including the .tpp file directly by throwing this error, is the MYCLASS_TPP define not reduntant?

– dave
Jan 25 at 10:24

2

@dave No. If your user first includes myclass.hpp and then myclass.tpp, the error won't fire.

– Max Langhof
Jan 25 at 10:26

1

I disagree with the sentence include guards are never needed. Suppose an header A.hpp needs to include another header B.hpp (because, for instance, it uses the definitions found in B.hpp), and suppose you write a code which needs both A.hpp and B.hpp. Unless you inspect the code of A.hpp, you would not know that #include "B.hpp" is not needed. Then, you would include both A.hpp and B.hpp, resulting in a double include of B.hpp. The include guard prevents this.

– francesco
Jan 25 at 10:43

1

@francesco There's always a way around, but its a bad way no-one should take: include guards are not needed: just terribly useful.

– YSC
Jan 25 at 10:44

2

@francesco The hair-splitting answer would be "#pragma once can also do it in basically any compiler".

– Max Langhof
Jan 25 at 10:45

|
show 4 more comments

1

Nice! Although if I prevent including the .tpp file directly by throwing this error, is the MYCLASS_TPP define not reduntant?

– dave
Jan 25 at 10:24

2

@dave No. If your user first includes myclass.hpp and then myclass.tpp, the error won't fire.

– Max Langhof
Jan 25 at 10:26

1

I disagree with the sentence include guards are never needed. Suppose an header A.hpp needs to include another header B.hpp (because, for instance, it uses the definitions found in B.hpp), and suppose you write a code which needs both A.hpp and B.hpp. Unless you inspect the code of A.hpp, you would not know that #include "B.hpp" is not needed. Then, you would include both A.hpp and B.hpp, resulting in a double include of B.hpp. The include guard prevents this.

– francesco
Jan 25 at 10:43

1

@francesco There's always a way around, but its a bad way no-one should take: include guards are not needed: just terribly useful.

– YSC
Jan 25 at 10:44

2

@francesco The hair-splitting answer would be "#pragma once can also do it in basically any compiler".

– Max Langhof
Jan 25 at 10:45

Nice! Although if I prevent including the .tpp file directly by throwing this error, is the MYCLASS_TPP define not reduntant?

– dave
Jan 25 at 10:24

@dave No. If your user first includes myclass.hpp and then myclass.tpp, the error won't fire.

– Max Langhof
Jan 25 at 10:26

I disagree with the sentence include guards are never needed. Suppose an header A.hpp needs to include another header B.hpp (because, for instance, it uses the definitions found in B.hpp), and suppose you write a code which needs both A.hpp and B.hpp. Unless you inspect the code of A.hpp, you would not know that #include "B.hpp" is not needed. Then, you would include both A.hpp and B.hpp, resulting in a double include of B.hpp. The include guard prevents this.

– francesco
Jan 25 at 10:43

@francesco There's always a way around, but its a bad way no-one should take: include guards are not needed: just terribly useful.

– YSC
Jan 25 at 10:44

@francesco The hair-splitting answer would be "#pragma once can also do it in basically any compiler".

– Max Langhof
Jan 25 at 10:45

|
show 4 more comments

On the other hand, include guard may be broken because the name of the macro will not be that unique, because of a copy/paste, or a header file created by first copying an other, etc...

How are chosen the unique macro name: <project name>_<filename>? How could it be more unique than a uniqueness based on the entire root directory structure?

So in the end, one should consider when choosing between include guard or pragma once, the cost of the job that is necessary to ensure uniqueness:

1 - For pragma once you only have to ensure that the directory structured of your system is not messed-out thanks to hard links.

2 - For include guard for each file on your system you should ensure that the macro name is unique.

I mean as a manager, evaluating the cost of this job and the failure risk does let only one option. Include guard are used only when no evaluation is performed: it is a non decision.

edited Jan 25 at 13:04

answered Jan 25 at 11:10

Oliv

9,4021957

2

I agree: if you control your build environment (e.g. this is a proprietary project) there's no reason not to use #pragma once. If you're writing an open source library you'd like to be used on obscures build environments (embedded, old systems, etc.), maybe just stick to include guards.

– YSC
Jan 25 at 12:09

@YSC Not writing but maintaining an old library. For a new library, that may be added to an old system, you just specify that this library should not be hardlinked and that all. There are no reason to make every body pay for an ancient practice that might still be in use by a number of people that can be count on the one hand. It is like asking million of coder to loose their time to improbably increase the productivity of 2 or 3 system administrator.

– Oliv
Jan 25 at 12:21

I was thinking about compilers too old/obscure to know #pragma once ;) But yes.

– YSC
Jan 25 at 12:22

I believe they both have their uses. Years ago not all compilers supported #pragma once, so many were forced to use header guards, however, most compilers today should fully support #pragma once without issue. Typically if I have a single header file that is a class' declaration I'll use header guards with the name of the class file where that class file is the name of the class. If I have a header file that has a bunch of macros, defines, constants and just stand alone function declarations, then I'll more than likely use #pragma once. This is just my preference.

– Francis Cugler
Jan 25 at 14:32

add a comment |

On the other hand, include guard may be broken because the name of the macro will not be that unique, because of a copy/paste, or a header file created by first copying an other, etc...

How are chosen the unique macro name: <project name>_<filename>? How could it be more unique than a uniqueness based on the entire root directory structure?

So in the end, one should consider when choosing between include guard or pragma once, the cost of the job that is necessary to ensure uniqueness:

1 - For pragma once you only have to ensure that the directory structured of your system is not messed-out thanks to hard links.

2 - For include guard for each file on your system you should ensure that the macro name is unique.

I mean as a manager, evaluating the cost of this job and the failure risk does let only one option. Include guard are used only when no evaluation is performed: it is a non decision.

edited Jan 25 at 13:04

answered Jan 25 at 11:10

Oliv

9,4021957

2

I agree: if you control your build environment (e.g. this is a proprietary project) there's no reason not to use #pragma once. If you're writing an open source library you'd like to be used on obscures build environments (embedded, old systems, etc.), maybe just stick to include guards.

– YSC
Jan 25 at 12:09

@YSC Not writing but maintaining an old library. For a new library, that may be added to an old system, you just specify that this library should not be hardlinked and that all. There are no reason to make every body pay for an ancient practice that might still be in use by a number of people that can be count on the one hand. It is like asking million of coder to loose their time to improbably increase the productivity of 2 or 3 system administrator.

– Oliv
Jan 25 at 12:21

I was thinking about compilers too old/obscure to know #pragma once ;) But yes.

– YSC
Jan 25 at 12:22

I believe they both have their uses. Years ago not all compilers supported #pragma once, so many were forced to use header guards, however, most compilers today should fully support #pragma once without issue. Typically if I have a single header file that is a class' declaration I'll use header guards with the name of the class file where that class file is the name of the class. If I have a header file that has a bunch of macros, defines, constants and just stand alone function declarations, then I'll more than likely use #pragma once. This is just my preference.

– Francis Cugler
Jan 25 at 14:32

add a comment |

On the other hand, include guard may be broken because the name of the macro will not be that unique, because of a copy/paste, or a header file created by first copying an other, etc...

How are chosen the unique macro name: <project name>_<filename>? How could it be more unique than a uniqueness based on the entire root directory structure?

So in the end, one should consider when choosing between include guard or pragma once, the cost of the job that is necessary to ensure uniqueness:

1 - For pragma once you only have to ensure that the directory structured of your system is not messed-out thanks to hard links.

2 - For include guard for each file on your system you should ensure that the macro name is unique.

I mean as a manager, evaluating the cost of this job and the failure risk does let only one option. Include guard are used only when no evaluation is performed: it is a non decision.

edited Jan 25 at 13:04

answered Jan 25 at 11:10

Oliv

9,4021957

On the other hand, include guard may be broken because the name of the macro will not be that unique, because of a copy/paste, or a header file created by first copying an other, etc...

How are chosen the unique macro name: <project name>_<filename>? How could it be more unique than a uniqueness based on the entire root directory structure?

So in the end, one should consider when choosing between include guard or pragma once, the cost of the job that is necessary to ensure uniqueness:

1 - For pragma once you only have to ensure that the directory structured of your system is not messed-out thanks to hard links.

2 - For include guard for each file on your system you should ensure that the macro name is unique.

I mean as a manager, evaluating the cost of this job and the failure risk does let only one option. Include guard are used only when no evaluation is performed: it is a non decision.

edited Jan 25 at 13:04

answered Jan 25 at 11:10

Oliv

9,4021957

edited Jan 25 at 13:04

answered Jan 25 at 11:10

Oliv

9,4021957

answered Jan 25 at 11:10

Oliv

9,4021957

answered Jan 25 at 11:10

Oliv

9,4021957

2

I agree: if you control your build environment (e.g. this is a proprietary project) there's no reason not to use #pragma once. If you're writing an open source library you'd like to be used on obscures build environments (embedded, old systems, etc.), maybe just stick to include guards.

– YSC
Jan 25 at 12:09

@YSC Not writing but maintaining an old library. For a new library, that may be added to an old system, you just specify that this library should not be hardlinked and that all. There are no reason to make every body pay for an ancient practice that might still be in use by a number of people that can be count on the one hand. It is like asking million of coder to loose their time to improbably increase the productivity of 2 or 3 system administrator.

– Oliv
Jan 25 at 12:21

I was thinking about compilers too old/obscure to know #pragma once ;) But yes.

– YSC
Jan 25 at 12:22

I believe they both have their uses. Years ago not all compilers supported #pragma once, so many were forced to use header guards, however, most compilers today should fully support #pragma once without issue. Typically if I have a single header file that is a class' declaration I'll use header guards with the name of the class file where that class file is the name of the class. If I have a header file that has a bunch of macros, defines, constants and just stand alone function declarations, then I'll more than likely use #pragma once. This is just my preference.

– Francis Cugler
Jan 25 at 14:32

add a comment |

2

I agree: if you control your build environment (e.g. this is a proprietary project) there's no reason not to use #pragma once. If you're writing an open source library you'd like to be used on obscures build environments (embedded, old systems, etc.), maybe just stick to include guards.

– YSC
Jan 25 at 12:09

@YSC Not writing but maintaining an old library. For a new library, that may be added to an old system, you just specify that this library should not be hardlinked and that all. There are no reason to make every body pay for an ancient practice that might still be in use by a number of people that can be count on the one hand. It is like asking million of coder to loose their time to improbably increase the productivity of 2 or 3 system administrator.

– Oliv
Jan 25 at 12:21

I was thinking about compilers too old/obscure to know #pragma once ;) But yes.

– YSC
Jan 25 at 12:22

I believe they both have their uses. Years ago not all compilers supported #pragma once, so many were forced to use header guards, however, most compilers today should fully support #pragma once without issue. Typically if I have a single header file that is a class' declaration I'll use header guards with the name of the class file where that class file is the name of the class. If I have a header file that has a bunch of macros, defines, constants and just stand alone function declarations, then I'll more than likely use #pragma once. This is just my preference.

– Francis Cugler
Jan 25 at 14:32

I agree: if you control your build environment (e.g. this is a proprietary project) there's no reason not to use #pragma once. If you're writing an open source library you'd like to be used on obscures build environments (embedded, old systems, etc.), maybe just stick to include guards.

– YSC
Jan 25 at 12:09

@YSC Not writing but maintaining an old library. For a new library, that may be added to an old system, you just specify that this library should not be hardlinked and that all. There are no reason to make every body pay for an ancient practice that might still be in use by a number of people that can be count on the one hand. It is like asking million of coder to loose their time to improbably increase the productivity of 2 or 3 system administrator.

– Oliv
Jan 25 at 12:21

I was thinking about compilers too old/obscure to know #pragma once ;) But yes.

– YSC
Jan 25 at 12:22

I believe they both have their uses. Years ago not all compilers supported #pragma once, so many were forced to use header guards, however, most compilers today should fully support #pragma once without issue. Typically if I have a single header file that is a class' declaration I'll use header guards with the name of the class file where that class file is the name of the class. If I have a header file that has a bunch of macros, defines, constants and just stand alone function declarations, then I'll more than likely use #pragma once. This is just my preference.

– Francis Cugler
Jan 25 at 14:32

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu