C语言中头文件是如何定义和实现相关函数的？

本文共计1224个文字，预计阅读时间需要5分钟。

（C语言）头文件中实现的函数+在C语言中，有时为了方便（方便的同义词是偷懒），函数就直接在头文件中实现了。那么这样子有什么问题呢？

问题可能包括：

1. 编译依赖性：如果头文件中的函数实现被修改，所有包含该头文件的源文件都需要重新编译，即使它们没有直接使用到这些函数。

2. 维护困难：将函数实现放在头文件中，使得头文件变得庞大且复杂，增加了维护难度。

3. 可读性降低：头文件中包含函数实现，使得头文件的内容变得混乱，降低了代码的可读性。

4. 版本控制问题：当头文件中的函数实现发生变化时，版本控制变得更加复杂，因为需要同时更新头文件和所有使用该头文件的源文件。

5. 编译效率降低：每次编译时，编译器都需要重新处理头文件中的函数实现，即使这些实现没有改变，这可能会降低编译效率。

以下是一个简单的例子：

c// myfunc.h#ifndef MYFUNC_H#define MYFUNC_H

void myFunction(int a, int b);

#endif // MYFUNC_H

// myfunc.c#include myfunc.h

void myFunction(int a, int b) { // 函数实现}

在这个例子中，`myfunc.h` 包含了函数原型，而 `myfunc.c` 包含了函数的实现。这样做可以保持代码的清晰和组织性。

（C语言）头文件实现的函数

在C语言里面，有时候为了方便（方便的同义词是偷懒），函数就直接在头文件里面实现了。那么这样子有什么问题呢？

下面举个例子，这个例子只有3个文件

/* fun.h */ #ifndef FUN_H #define FUN_H void base(){}; void fun(); #endif /* fun.c */ #include "fun.h" void fun() { base(); } /* main.c */ #include "fun.h" int main() { fun(); return 0; }

好，然后gcc一下

gcc -c main.c （通过）
gcc -c fun.c （通过）
gcc -o main main.o fun.o （链接错误）

出现错误...“base()函数重定义!”

为什么重定义呢？因为#include是预处理部分，在编译之前由预处理程序在这个部分复制头文件的内容过来。所以在编译时候，main.o和fun.o文件都有base()函数的定义。那么链接程序就不知道链接那个定义好了（二义性啊）

如何解决呢，为了实现“声明和实现分开”这个目标最好就是把这个base函数的函数体移到源文件里面。如果由于某种原因真的要放在头文件中...也可以。

用static声明就可以了，静态函数的作用域是文件，而不是全局。比如，上面的例子将头文件里面的void base(){}改成static void base(){}，那就OK。

这个static在c语言中的用法可以google下，上面的资料好多很详细滴。

顺便说说头文件的循环依赖的问题。

比如有三个头文件a.h b.h c.h，a.h里面有#include "b.h",b.h里面有#include "c.h", c.h里面有#include "a.h"，那就会造成文件的循环依赖，后果是什么呢？

比如有个文件a.c，上面有#include "a.h"，那在a.c文件编译之前，预处理程序就会不断的把这三个头文件的内容复制过来，超过了一定的数量，就会导致“头文件数太多”的编译错误。

解决方法呢，当然就是常见的#ifndef...#define...#endif组合了。不过要把前两个写在头文件的开头（一定是开头），最后一个写在最末尾。

这样的话，第一次展开a.h b.h c.h的时候就已经定义了宏，到了c.h中的#include "a.h"时候，遇到了#ifndef，由于这个宏在上一次展开时已经定义了，所以这部分就跳过去了。也就是每个头文件最多只在每个源文件里面包含一次。

但是即使编译链接没有问题，循环依赖也会降低开发效率，为什么？因为文件都在依赖，比如某一天，要改变a.h的一部分内容，然后所有依赖于a.h b.h c.h的文件都得重新编译...链接；所以现在的C++有“前向声明”的技巧可以缓解这个问题。（缓解并不是解决。）而JAVA运用的import机制就很好的解决了这个问题，真正实现了“实现与声明相分离”这个目标。