Is there a situation where you do not want to include security guards?

Question

I know why there are fences and that #pragma once not standard and therefore not supported by all compilers, etc.

My question has a different look:

Is there a reasonable reason to never have them? I have not yet encountered a situation where, in theory, it would be advantageous not to include the included guards in a file intended for inclusion in another place. Does anyone have an example where there is a real benefit from their absence?

The reason I ask them is that they seem pretty redundant, since you always use them, and that the #pragma once behavior can simply be automatically applied to literally everything.

Answer 1

I saw headers that generate code depending on the macros defined before they were included. In this case, sometimes I wanted to define these macros for one (set) of values, turn on the header, redefine the macros, and turn it on again.
Everyone who sees this agrees that it is ugly and better avoided, but sometimes (for example, if the code in the headers is generated in some other way), this is less evil for that.

Other than that, I cannot think of a reason.

Answer 2

@sbi has already talked about code generation, so let me give you an example.

Say that you have an enumeration of many elements and that you want to create a bunch of functions for each of your elements ...

One solution is to use this multiple inclusion trick.

 // myenumeration.td MY_ENUMERATION_META_FUNCTION(Item1) MY_ENUMERATION_META_FUNCTION(Item2) MY_ENUMERATION_META_FUNCTION(Item3) MY_ENUMERATION_META_FUNCTION(Item4) MY_ENUMERATION_META_FUNCTION(Item5) 

Then people just use it like this:

 #define MY_ENUMERATION_META_FUNCTION(Item_) \ case Item_: return #Item_; char const* print(MyEnum i) { switch(i) { #include "myenumeration.td" } __unreachable__("print"); return 0; // to shut up gcc } #undef MY_ENUMERATION_META_FUNCTION 

Whether this is good or hacking is up to you, but it is certainly useful not to scan all the functions of the utilities every time a new value is added to the enumeration.

Answer 3

 <cassert> <assert.h> 

"The approval macro is redefined according to the current state of NDEBUG every time <assert.h>."

Answer 4

This can be a problem if the project has two headers that use the same protector, for example. if you have two third-party libraries, and both of them have a header that uses the include security character, such as __CONSTANTS_H__ , then you cannot successfully #include both headers in this compilation unit. The best solution is #pragma once , but some older compilers do not support this.

Answer 5

Suppose you have a third-party library and you cannot change its code. Now suppose files from this library generate compiler warnings. Usually you want to compile your own code with a high level of warnings, but this will create a large set of warnings about using the library. You could write warning disabler / enabler headers, which could then wrap a third-party library, and they should be included multiple times.

Another more complex use case is the Boost Preprocessor iterative construct: http://www.boost.org/doc/libs/1_46_0/libs/preprocessor/doc/index.html

Answer 6

C # pragma's problem once and the reason it is not part of the standard is because it does not always work everywhere. How does the compiler know if two files are the same file or not if they are included from different paths?

Think about what would happen if the compiler made a mistake and did not include the file that it was supposed to include? What happens if it contains a file twice that it should not have? How do you fix this?

With the guards turned on, the worst that can happen is that it takes a little longer to compile.

Edit: Look at this topic at comp.std.C ++ "#pragma once in the ISO standard yet?"

http://groups.google.com/group/comp.std.c++/browse_thread/thread/c527240043c8df92