C语言 我需要在 C 程序中编译头文件吗？

Do I need to compile the header files in a C program?

提问by yuliu

Sometimes I see someone compile a C program like this:

有时我看到有人像这样编译一个 C 程序：

gcc -o hello hello.c hello.h

gcc -o hello hello.c hello.h

As I know, we just need to put the header files into the C program like:

据我所知，我们只需要将头文件放入 C 程序中，例如：

#include "somefile"

#include "somefile"

and compile the C program: gcc -o hello hello.c.

并编译C程序：gcc -o hello hello.c。

When do we need to compile the header files or why?

我们什么时候需要编译头文件或者为什么？

采纳答案by AnT

Firstly, in general:

首先，一般来说：

If these .hfiles are indeed typical C-style header files (as opposed to being something completely different that just happens to be named with .hextension), then no, there's no reason to "compile" these header files independently. Header files are intended to be included into implementation files, not fed to the compiler as independent translation units.

如果这些.h文件确实是典型的 C 风格头文件（而不是完全不同的东西，只是碰巧以.h扩展名命名），那么不，没有理由独立“编译”这些头文件。头文件旨在包含在实现文件中，而不是作为独立的翻译单元提供给编译器。

Since a typical header file usually contains only declarations that can be safely repeated in each translation unit, it is perfectly expected that "compiling" a header file will have no harmful consequences. But at the same time it will not achieve anything useful.

由于典型的头文件通常只包含可以在每个翻译单元中安全重复的声明，因此完全可以预期“编译”头文件不会产生有害后果。但同时它也不会实现任何有用的东西。

Basically, compiling hello.has a standalone translation unit equivalent to creating a degenerate dummy.cfile consisting only of #include "hello.h"directive, and feeding that dummy.cfile to the compiler. It will compile, but it will serve no meaningful purpose.

基本上，hello.h作为独立的翻译单元编译相当于创建一个dummy.c仅包含#include "hello.h"指令的退化文件，并将该dummy.c文件提供给编译器。它会编译，但它没有任何意义。

---

---

Secondly, specifically for GCC:

其次，专门针对GCC：

Many compilers will treat files differently depending on the file name extension. GCC has special treatment for files with .hextension when they are supplied to the compiler as command-line arguments. Instead of treating it as a regular translation unit, GCC creates a precompiled headerfile for that .hfile.

许多编译器会根据文件扩展名对文件进行不同的处理。GCC 对带有.h扩展名的文件作为命令行参数提供给编译器时有特殊处理。GCC 没有将其视为常规翻译单元，而是为该文件创建了一个预编译的头.h文件。

You can read about it here: http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

你可以在这里阅读：http: //gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

So, this is the reason you might see .hfiles being fed directly to GCC.

因此，这就是您可能会看到.h文件被直接馈送到 GCC 的原因。

回答by Alexander Mihailov

Okay, let's understand the difference between active and passive code.

好的，让我们了解主动代码和被动代码之间的区别。

The active code is the implementation of functions, procedures, methods, i.e. the pieces of code that should be compiled to executable machine code. We store it in .c files and sure we need to compile it.

活动代码是函数、过程、方法的实现，即应该编译为可执行机器代码的代码段。我们将它存储在 .c 文件中，并确保我们需要编译它。

The passive code is not being execute itself, but it needed to explain the different modules how to communicate with each other. Usually, .h files contains only prototypes (function headers), structures.

被动代码本身并不被执行，但它需要解释不同的模块如何相互通信。通常，.h 文件只包含原型（函数头）、结构。

An exception are macros, that formally can contain an active pieces, but you should understand that they are using at the very early stage of building (preprocessing) with simple substitution. At the compile time macros already are substituted to your .c file.

宏是一个例外，它正式可以包含活动部分，但您应该了解它们在构建（预处理）的早期阶段使用简单替换。在编译时宏已经替换为您的 .c 文件。

Another exception are C++ templates, that should be implemented in .h files. But here is the story similar to macros: they are substituted on the early stage (instantiation) and formally, each other instantiation is another type.

另一个例外是 C++ 模板，它应该在 .h 文件中实现。但这里有一个类似于宏的故事：它们在早期（实例化）和形式上被替换，彼此的实例化是另一种类型。

In conclusion, I think, if the modules formed properly, we should never compile the header files.

总之，我认为，如果模块构成正确，我们永远不应该编译头文件。

回答by How Chen

I think we do need preprocess(maybe NOT call the compile) the head file. Because from my understanding, during the compile stage, the head file should be included in c file. For example, in test.h we have

我认为我们确实需要预处理（可能不调用编译）头文件。因为按照我的理解，在编译阶段，头文件应该包含在c文件中。例如，在 test.h 我们有

typedef enum{
    a,
    b,
    c
}test_t

and in test.c we have

在 test.c 中我们有

void foo()
{
    test_t test;
    ...
}

during the compile, i think the compiler will put the code in head file and c file together and code in head file will be pre-processed and substitute the code in c file. Meanwhile, we'd better to define the include path in makefile.

在编译过程中，我认为编译器会将头文件和c文件中的代码放在一起，头文件中的代码将被预处理并替换c文件中的代码。同时，我们最好在makefile中定义包含路径。

回答by Edwin Buck

In some systems, attempts to speed up the assembly of fully resolved '.c' files call the pre-assembly of include files "compiling header files". However, it is an optimization technique that is not necessary for actual C development.

在某些系统中，试图加速完全解析的 '.c' 文件的组装将包含文件的预组装称为“编译头文件”。但是，它是一种优化技术，对于实际的 C 开发来说并不是必需的。

Such a technique basically computed the include statements and kept a cache of the flattened includes. Normally the C toolchain will cut-and-paste in the included files recursively, and then pass the entire item off to the compiler. With a pre-compiled header cache, the tool chain will check to see if any of the inputs (defines, headers, etc) have changed. If not, then it will provide the already flattened text file snippets to the compiler.

这种技术基本上计算了包含语句并保留了扁平包含的缓存。通常，C 工具链会递归地剪切和粘贴包含的文件，然后将整个项目传递给编译器。使用预编译的头缓存，工具链将检查是否有任何输入（定义、头等）发生了变化。如果没有，那么它将向编译器提供已经扁平化的文本文件片段。

Such systems were intended to speed up development; however, many such systems were quite brittle. As computers sped up, and source code management techniques changed, fewer of the header pre-compilers are actually used in the common project.

此类系统旨在加快开发速度；然而，许多这样的系统非常脆弱。随着计算机速度的提高和源代码管理技术的变化，公共项目中实际使用的头文件预编译器越来越少。

Until you actually need compilation optimization, I highly recommend you avoid pre-compiling headers.

在您真正需要编译优化之前，我强烈建议您避免预编译头文件。

回答by aaron34weston

You don't need to compile header files. It doesn't actually do anything, so there's no point in trying to run it. However, it is a great way to check for typos and mistakes and bugs, so it'll be easier later.

您不需要编译头文件。它实际上并没有做任何事情，因此尝试运行它是没有意义的。但是，这是检查拼写错误和错误的好方法，因此以后会更容易。