为什么我的包含保护不会阻止递归包含和多个符号定义？ [英] Why aren't my include guards preventing recursive inclusion and multiple symbol definitions?

问题描述

有关包含警卫的两个常见问题：

1. 第一个问题：

   
   
   

   为什么不包含保护我的头文件不受递归包含？我不断收到关于不存在的符号的错误，显然存在，甚至更糟糕的语法错误，每次我写下如下：

   
   
   

   ah

     #ifndef A_H 
    #define A_H 
    
    #includebh
    
    ... 
    
    #endif // A_H 
     

   bh p>
   
   

     #ifndef B_H 
    #define B_H 
    
    #includeah
    
    ... 
    
    #endif // B_H 
     

   main .cpp
   
   

     #includeah
    int main（）
    {
   。 .. 
   } 
     

   为什么编译main.cpp我需要做什么来解决我的问题？

---

< 2>

第二个问题：

为什么不包括防护<定义？例如，当我的项目包含两个包含相同标题的文件时，有时链接器会报告一些符号被定义多次。例如：

header.h

  #ifndef HEADER_H 
 #define HEADER_H 
 
 int f（）
 {
 return 0; 
} 
 
 #endif // HEADER_H 
  

source1。 cpp

  #includeheader.h
 ... 
  

source2.cpp

  #include header.h
 ... 
  

为什么会发生这种情况？我需要做什么来解决我的问题？

解决方案

第一个问题：

为什么不包含保护我的头文件不受 strong>？

。

他们不帮助的是在相互包含的标题中的数据结构的定义之间的依赖性。为了看看这是什么意思，让我们从一个基本的场景开始，看看为什么包含守卫帮助相互包含。

假设你们相互包含 / code>和 bh 头文件具有微不足道的内容，即来自问题文本的代码段中的省略号被替换为空字符串。在这种情况下，您的 main.cpp 将很乐意编译。

如果您不确信，请尝试移除它们：

<$> p $ p> // ====================================== ==========
// ah

#includebh

// ========== ==================================
// bh

#includeah

// ============================== ================
// main.cpp
//
//好运，要编译...

#includeah
int main（）
{
...
}


您会注意到，当编译器达到包含深度限制时，它会报告失败。此限制是实现特定的。根据C ++ 11标准的第16.2 / 6段：

#include预处理指令可能出现在已读取的源文件中因为在另一个文件中有一个#include指令，达到实现定义的嵌套限制。

strong>所以发生了什么？

1. 解析 main.cpp ，则预处理器将满足指令 #includeah。这个指令告诉预处理器处理头文件 ah ，取处理结果，并替换 #includeah> 时，预处理器将满足指令 #include bh，并且同样的机制适用：预处理器将处理头文件 bh ，取其处理结果， code> #include 指令;


2. 当处理 bh code> #includeah会告诉预处理器处理 ah 并用结果替换该指令;


3. 预处理器将再次开始解析 ah ，将再次满足 #includebh ，这将设置一个潜在的无限递归过程。

当包含保护存在时，编译器会报告错误。让我们来看看为什么：

1. （ ）当解析 main.cpp 时，预处理器将满足指令 #includeah。这告诉预处理器处理头文件 ah ，取处理结果，并替换 #includeah; c $> c> 。由于宏 A_H 尚未定义，它将继续处理以下文本。随后的指令（ #defines A_H ）定义了 A_H 的宏。然后，预处理器将满足指令 #includebh：预处理器现在将处理头文件 bh 取得其处理结果，并用该结果替换 #include 指令;


2. 处理 bh ，预处理器将满足指令 #ifndef B_H 。由于宏 B_H 尚未定义，它将继续处理以下文本。后续指令（ #defines B_H ）定义了 B_H 的宏。然后，指令 #includeah将告诉预处理器处理 ah 并替换 ah ; c> 中的#include
   
3. 编译器将再次开始预处理 ah ，并再次满足 #ifndef A_H 指令。但是，在之前的预处理期间，已定义宏 A_H 。因此，编译器将跳过下面的文本，直到找到匹配的 #endif 指令，并且这个处理的输出是空字符串（假设没有跟随 #endif 指令，当然）。因此，预处理器将用空字符串替换 bh 中的 #includeah指令，直到它替换 main.cpp 中的原始 #include 指令。






因此，包含守卫确保防止相互包含。但是，他们无法帮助您在相互包含的文件中的类定义之间的依赖关系：

  // ============================================ == 
 // ah 
 
 #ifndef A_H 
 #define A_H 
 
 #includebh
 
 struct A 
 {
}; 
 
 #endif // A_H 
 
 // ============================= ======================= 
 // bh 
 
 #ifndef B_H 
 #define B_H 
 
 #includeah
 
 struct B 
 {
 A * pA; 
}; 
 
 #endif // B_H 
 
 // ============================= ===================== 
 // main.cpp 
 // 
 //祝你好运这个编译.. 。
 
 #includeah
 int main（）
 {
 ... 
} 
  

鉴于上述标题， main.cpp 将无法编译。




为什么会发生这种情况？




足以再次通过步骤1-4。





很容易看到，前三个步骤和大部分的第四步都不受此更改的影响（只读通过它们来说服）。但是，在第4步结束时会发生不同的情况：在 bh 中替换 #includeah空字符串，预处理器将开始解析 bh 的内容，特别是 B 的定义。不幸的是， B 的定义提到了类 A ，从来没有满足过，因为包括守卫！





声明一个以前没有声明的类型的成员变量当然是一个错误，编译器会礼貌地指出这一点。




我需要做什么来解决我的问题？




您需要 转发声明 。





实际上，为了定义类 B A 的定义 c>，因为指针到 A 被声明为成员变量，而不是类型 A 。由于指针具有固定大小，因此编译器不需要知道 A 的确切布局，也不必计算其大小以正确定义 B 。因此，在 bh 中前向声明类 A 就足够了，意识到其存在：

  // ===================== =========================== 
 // bh 
 
 #ifndef B_H 
 #define B_H 
 
 // A的前向声明：无需#includeah
 struct A; 
 
 struct B 
 {
 A * pA; 
}; 
 
 #endif // B_H 
  

您的 main .cpp 现在肯定会编译。以下几句话：



1. 不仅打破了相互包容，取代了 #include bh 中的向前声明足以有效地表示 B 在 A ：尽可能使用转发声明/实用也被视为良好的编程习惯，因为它有助于避免不必要的包含，从而缩短整体编译时间。但是，在消除相互包含之后， main.cpp 将必须修改为 #include 两者 ah 和 bh （如果后者是必需的），因为 bh 不再间接 #include d到 ah ;


2. 声明类 A 足以让编译器声明指向该类的指针（或者在任何其他不完整类型可接受的上下文中使用它），解引用指向 A （例如调用成员函数）或计算其大小是对不完全类型的非法操作：如果需要， $ c> A 需要可用于编译器，这意味着必须包括定义它的头文件。这就是为什么类定义和它们的成员函数的实现通常被分成头文件和该类的实现文件（类 templates 是这个规则的例外）：实现文件， #include d通过项目中的其他文件，可以安全地 #include 所有必要的标题，使定义可见。另一方面，头文件不会 #include 其他头文件，除非他们真的需要这样做（例如，使可见的基类的定义），并且只要可能/实用就会使用前缀声明。










第二个问题：





为什么不包含防护多个定义 p>






保护您免受单独翻译单位中的多个定义 。这也在 此问答;





看到，尝试删除包含守卫并编译以下修改版本的 source1.cpp （或 source2.cpp ）：

  // ====================================== ========== 
 // source1.cpp 
 // 
 //祝你好运这个编译... 
 
 #include header.h
 #includeheader.h
 
 int main（）
 {
 ... 
} 
  

编译器肯定会在这里抱怨 f（）被重新定义。这很明显：它的定义被包括两次！然而，当 header.h 包含正确的包含卫士时，上述 source1.cpp / strong>。这是预期。





仍然，即使存在包含守卫，并且编译器将停止打扰您的错误消息，链接器将坚持以下事实：在合并从 source1.cpp 和 source2.cpp 的编译中获得的对象代码时会发现多个定义，拒绝生成您的可执行文件。




为什么会发生这种情况？





b $ b

基本上，您的项目中的每个 .cpp 文件（此上下文中的技术术语是翻译单元）是单独编译的，独立 。当解析 .cpp 文件时，预处理器将处理所有 #include 指令，并展开它遇到的所有宏调用，并且该纯文本处理的输出将被输入到编译器中以将其转换为目标代码。一旦编译器完成生成一个翻译单元的目标代码，它将继续下一个翻译单元，并且将会忘记在处理先前翻译单元时遇到的所有宏定义。





事实上，用 n 翻译单位（ .cpp 文件）类似于执行相同的程序（编译器） n 次，每次输入不同：同一程序的不同执行< t共享先前程序执行的状态。因此，每个翻译都是独立执行的，编译一个翻译单元时遇到的预处理器符号在编译其他翻译单元时不会被记住（如果你仔细想一下，你会很容易意识到这实际上是一个理想的行为）。





因此，即使包含守卫帮助您防止在一个翻译单元中相同标题的递归相互包含和冗余包含，是否在不同翻译单元中包括相同的定义。





然而，当合并从项目的所有 .cpp 文件的编译生成的对象代码时，链接器 将查看相同的符号被多次定义，因为这违反了 一个定义规则 。根据C ++ 11标准的第3.2 / 3节：




每个程序应该包含每个< 在该程序中使用的函数或变量;无需诊断。定义可以在程序中显式显示，它可以在标准或用户定义的库中找到，或者（在适当的时候）被隐式定义（见12.1,12.4和12.8）。 内联函数应在其使用的每个翻译单元中定义

。




链接器将发出错误并拒绝生成您的程序的可执行文件。




我需要做什么来解决我的问题？ / p>


如果要将函数定义保留在包括 d由多个翻译单位（通知，如果您的标题 #include 一个翻译单元），您需要使用 inline 关键字。





否则，您只需要在 header.h 声明 >，将其定义（正文）放入一个分隔 .cpp 文件（这是经典的方法）。





inline 关键字表示对编译器直接在调用点处内联函数体的非绑定请求，而不是设置堆栈帧用于常规函数调用。虽然编译器不必满足您的请求，但 inline 关键字确实成功告诉链接器允许多个符号定义。根据C ++ 11标准的第3.2 / 5段：




强类>类类型（条款9），枚举类型（7.2），具有外部链接的内联函数（7.1.2），类模板（14），非静态函数模板，类模板的静态数据成员（14.5.1.3），类模板的成员函数（14.5.1.1），或者在程序中未指定某些模板参数（14.7,14.5.5）的模板特化， [...]




上述段落基本上列出了通常放在头文件中的所有定义，因为它们可以安全地包含在多个翻译单元中。所有其他具有外部链接的定义都属于源文件。





使用 static 关键字而不是 inline 关键字也会通过提供您的函数 internal链接 ，从而使每个翻译单元保存该函数（及其本地静态变量）的私有副本。但是，这最终会导致更大的可执行文件，并且通常优先使用 inline 。





使用 static 关键字实现相同结果的另一种方法是将函数 f（）未命名命名空间。根据C ++ 11标准的第3.5 / 4节：




未命名的命名空间或在未命名命名空间内直接或间接声明的命名空间内部连接。所有其他命名空间具有外部链接。如果名称的名称为：





- 一个变量;如果名称空间范围没有给出内部链接，则该名称具有与包围命名空间相同的链接。或





- 功能;或





- 一个命名类（第9条）或在typedef声明中定义的未命名类，其中类具有用于链接目的的typedef名称（7.1.3） ;或





- 一个命名枚举（7.2）或在typedef声明中定义的未命名枚举，其中枚举具有用于链接目的的typedef名称（7.1.3）;或





- 属于具有连接的枚举的枚举器;




由于上述同样的原因，应优先使用 inline 关键字。




Two common questions about include guards:

1. FIRST QUESTION:

   Why aren't include guards protecting my header files from mutual, recursive inclusion? I keep getting errors about non-existing symbols which are obviously there or even weirder syntax errors every time I write something like the following:

   "a.h"

   #ifndef A_H
   #define A_H
   
   #include "b.h"
   
   ...
   
   #endif // A_H
   

   "b.h"

   #ifndef B_H
   #define B_H
   
   #include "a.h"
   
   ...
   
   #endif // B_H
   

   "main.cpp"

   #include "a.h"
   int main()
   {
       ...
   }
   

   Why do I get errors compiling "main.cpp"? What do I need to do to solve my problem?

---

2. SECOND QUESTION:

   Why aren't include guards preventing multiple definitions? For instance, when my project contains two files that include the same header, sometimes the linker complains about some symbol being defined multiple times. For instance:

   "header.h"

   #ifndef HEADER_H
   #define HEADER_H
   
   int f()
   {
       return 0;
   }
   
   #endif // HEADER_H
   

   "source1.cpp"

   #include "header.h"
   ...
   

   "source2.cpp"

   #include "header.h"
   ...
   

   Why is this happening? What do I need to do to solve my problem?

解决方案

FIRST QUESTION:

Why aren't include guards protecting my header files from mutual, recursive inclusion?

They are.

What they are not helping with is dependencies between the definitions of data structures in mutually-including headers. To see what this means, let's start with a basic scenario and see why include guards do help with mutual inclusions.

Suppose your mutually including a.h and b.h header files have trivial content, i.e. the ellipses in the code sections from the question's text are replaced with the empty string. In this situation, your main.cpp will happily compile. And this is only thanks to your include guards!

If you're not convinced, try removing them:

//================================================
// a.h

#include "b.h"

//================================================
// b.h

#include "a.h"

//================================================
// main.cpp
//
// Good luck getting this to compile...

#include "a.h"
int main()
{
    ...
}

You'll notice that the compiler will report a failure when it reaches the inclusion depth limit. This limit is implementation-specific. Per Paragraph 16.2/6 of the C++11 Standard:

A #include preprocessing directive may appear in a source file that has been read because of a #include directive in another file, up to an implementation-defined nesting limit.

So what's going on?

1. When parsing main.cpp, the preprocessor will meet the directive #include "a.h". This directive tells the preprocessor to process the header file a.h, take the result of that processing, and replace the string #include "a.h" with that result;
2. While processing a.h, the preprocessor will meet the directive #include "b.h", and the same mechanism applies: the preprocessor shall process the header file b.h, take the result of its processing, and replace the #include directive with that result;
3. When processing b.h, the directive #include "a.h" will tell the preprocessor to process a.h and replace that directive with the result;
4. The preprocessor will start parsing a.h again, will meet the #include "b.h" directive again, and this will set up a potentially infinite recursive process. When reaching the critical nesting level, the compiler will report an error.

When include guards are present, however, no infinite recursion will be set up in step 4. Let's see why:

1. (same as before) When parsing main.cpp, the preprocessor will meet the directive #include "a.h". This tells the preprocessor to process the header file a.h, take the result of that processing, and replace the string #include "a.h" with that result;
2. While processing a.h, the preprocessor will meet the directive #ifndef A_H. Since the macro A_H has not yet been defined, it will keep processing the following text. The subsequent directive (#defines A_H) defines the macro A_H. Then, the preprocessor will meet the directive #include "b.h": the preprocessor shall now process the header file b.h, take the result of its processing, and replace the #include directive with that result;
3. When processing b.h, the preprocessor will meet the directive #ifndef B_H. Since the macro B_H has not yet been defined, it will keep processing the following text. The subsequent directive (#defines B_H) defines the macro B_H. Then, the directive #include "a.h" will tell the preprocessor to process a.h and replace the #include directive in b.h with the result of preprocessing a.h;
4. The compiler will start preprocessing a.h again, and meet the #ifndef A_H directive again. However, during previous preprocessing, macro A_H has been defined. Therefore, the compiler will skip the following text this time until the matching #endif directive is found, and the output of this processing is the empty string (supposing nothing follows the #endif directive, of course). The preprocessor will therefore replace the #include "a.h" directive in b.h with the empty string, and will trace back the execution until it replaces the original #include directive in main.cpp.

Thus, include guards do protect against mutual inclusion. However, they can't help with dependencies between the definitions of your classes in mutually-including files:

//================================================
// a.h

#ifndef A_H
#define A_H

#include "b.h"

struct A
{
};

#endif // A_H

//================================================
// b.h

#ifndef B_H
#define B_H

#include "a.h"

struct B
{
    A* pA;
};

#endif // B_H

//================================================
// main.cpp
//
// Good luck getting this to compile...

#include "a.h"
int main()
{
    ...
}

Given the above headers, main.cpp will not compile.

Why is this happening?

To see what's going on, it is enough to go through steps 1-4 again.

It is easy to see that the first three steps and most of the fourth step are unaffected by this change (just read through them to get convinced). However, something different happens at the end of step 4: after replacing the #include "a.h" directive in b.h with the empty string, the preprocessor will start parsing the content of b.h and, in particular, the definition of B. Unfortunately, the definition of B mentions class A, which has never been met before exactly because of the inclusion guards!

Declaring a member variable of a type which has not been previously declared is, of course, an error, and the compiler will politely point that out.

What do I need to do to solve my problem?

You need forward declarations.

In fact, the definition of class A is not required in order to define class B, because a pointer to A is being declared as a member variable, and not an object of type A. Since pointers have fixed size, the compiler won't need to know the exact layout of A nor to compute its size in order to properly define class B. Hence, it is enough to forward-declare class A in b.h and make the compiler aware of its existence:

//================================================
// b.h

#ifndef B_H
#define B_H

// Forward declaration of A: no need to #include "a.h"
struct A;

struct B
{
    A* pA;
};

#endif // B_H

Your main.cpp will now certainly compile. A couple of remarks:

1. Not only breaking the mutual inclusion by replacing the #include directive with a forward declaration in b.h was enough to effectively express the dependency of B on A: using forward declarations whenever possible/practical is also considered to be a good programming practice, because it helps avoiding unnecessary inclusions, thus reducing the overall compilation time. However, after eliminating the mutual inclusion, main.cpp will have to be modified to #include both a.h and b.h (if the latter is needed at all), because b.h is no more indirectly #included through a.h;
2. While a forward declaration of class A is enough for the compiler to declare pointers to that class (or to use it in any other context where incomplete types are acceptable), dereferencing pointers to A (for instance to invoke a member function) or computing its size are illegal operations on incomplete types: if that is needed, the full definition of A needs to be available to the compiler, which means the header file that defines it must be included. This is why class definitions and the implementation of their member functions are usually split into a header file and an implementation file for that class (class templates are an exception to this rule): implementation files, which are never #included by other files in the project, can safely #include all the necessary headers to make definitions visible. Header files, on the other hand, won't #include other header files unless they really need to do so (for instance, to make the definition of a base class visible), and will use forward-declarations whenever possible/practical.

SECOND QUESTION:

Why aren't include guards preventing multiple definitions?

They are.

What they are not protecting you from is multiple definitions in separate translation units. This is also explained in this Q&A on StackOverflow.

Too see that, try removing the include guards and compiling the following, modified version of source1.cpp (or source2.cpp, for what it matters):

//================================================
// source1.cpp
//
// Good luck getting this to compile...

#include "header.h"
#include "header.h"

int main()
{
    ...
}

The compiler will certainly complain here about f() being redefined. That's obvious: its definition is being included twice! However, the above source1.cpp will compile without problems when header.h contains the proper include guards. That's expected.

Still, even when the include guards are present and the compiler will stop bothering you with error message, the linker will insist on the fact that multiple definitions being found when merging the object code obtained from the compilation of source1.cpp and source2.cpp, and will refuse to generate your executable.

Why is this happening?

Basically, each .cpp file (the technical term in this context is translation unit) in your project is compiled separately and independently. When parsing a .cpp file, the preprocessor will process all the #include directives and expand all macro invocations it encounters, and the output of this pure text processing will be given in input to the compiler for translating it into object code. Once the compiler is done with producing the object code for one translation unit, it will proceed with the next one, and all the macro definitions that have been encountered while processing the previous translation unit will be forgotten.

In fact, compiling a project with n translation units (.cpp files) is like executing the same program (the compiler) n times, each time with a different input: different executions of the same program won't share the state of the previous program execution(s). Thus, each translation is performed independently and the preprocessor symbols encountered while compiling one translation unit will not be remembered when compiling other translation units (if you think about it for a moment, you will easily realize that this is actually a desirable behavior).

Therefore, even though include guards help you preventing recursive mutual inclusions and redundant inclusions of the same header in one translation unit, they can't detect whether the same definition is included in different translation unit.

Yet, when merging the object code generated from the compilation of all the .cpp files of your project, the linker will see that the same symbol is defined more than once, and since this violates the One Definition Rule. Per Paragraph 3.2/3 of the C++11 Standard:

Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the standard or a user-defined library, or (when appropriate) it is implicitly defined (see 12.1, 12.4 and 12.8). An inline function shall be defined in every translation unit in which it is odr-used.

Hence, the linker will emit an error and refuse to generate the executable of your program.

What do I need to do to solve my problem?

If you want to keep your function definition in a header file that is #included by multiple translation units (notice, that no problem will arise if your header is #included just by one translation unit), you need to use the inline keyword.

Otherwise, you need to keep only the declaration of your function in header.h, putting its definition (body) into one separate .cpp file only (this is the classical approach).

The inline keyword represents a non-binding request to the compiler to inline the function's body directly at the call site, rather than setting up a stack frame for a regular function call. Although the compiler doesn't have to fulfill your request, the inline keyword does succeed in telling the linker to tolerate multiple symbol definitions. According to Paragraph 3.2/5 of the C++11 Standard:

There can be more than one definition of a class type (Clause 9), enumeration type (7.2), inline function with external linkage (7.1.2), class template (Clause 14), non-static function template (14.5.6), static data member of a class template (14.5.1.3), member function of a class template (14.5.1.1), or template specialization for which some template parameters are not specified (14.7, 14.5.5) in a program provided that each definition appears in a different translation unit, and provided the definitions satisfy the following requirements [...]

The above Paragraph basically lists all the definitions which are commonly put in header files, because they can be safely included in multiple translation units. All other definitions with external linkage, instead, belong in source files.

Using the static keyword instead of the inline keyword also results in suppressing linker errors by giving your function internal linkage, thus making each translation unit hold a private copy of that function (and of its local static variables). However, this eventually results in a larger executable, and the use of inline should be preferred in general.

An alternative way of achieving the same result as with the static keyword is to put function f() in an unnamed namespace. Per Paragraph 3.5/4 of the C++11 Standard:

An unnamed namespace or a namespace declared directly or indirectly within an unnamed namespace has internal linkage. All other namespaces have external linkage. A name having namespace scope that has not been given internal linkage above has the same linkage as the enclosing namespace if it is the name of:

— a variable; or

— a function; or

— a named class (Clause 9), or an unnamed class defined in a typedef declaration in which the class has the typedef name for linkage purposes (7.1.3); or

— a named enumeration (7.2), or an unnamed enumeration defined in a typedef declaration in which the enumeration has the typedef name for linkage purposes (7.1.3); or

— an enumerator belonging to an enumeration with linkage; or

— a template.

For the same reason mentioned above, the inline keyword should be preferred.

这篇关于为什么我的包含保护不会阻止递归包含和多个符号定义？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！