c - 为什么某些声明为 extern 的函数和头文件未包含在 Git 源代码的源代码中？

Question

我想查看真实世界应用程序的源代码以了解良好的编程实践等。所以我选择了 Git 并下载了 1.8.4 版的源代码。

在随机浏览各种文件后，这两个文件引起了我的注意:strbuf.h strbuf.c

这两个文件显然用 this documentation 定义了一个 API。 .

我有两个问题:

为什么 'strbuf.h' 中第 16、17、18、19 行的函数声明和第 6 行的全局变量声明为 extern ？

为什么“strbuf.h”不包含在 strbuf .c 中？

作为一名新手程序员，我一直都知道你在 .c 文件中编写函数定义，而函数声明、宏、内联等编写在 .h 文件中，然后 #included 在每个想要使用这些的 .c 文件中功能等

任何人都可以解释一下吗？

Answer 1

strbuf.c包括 cache.h和 cache.h包括 strbuf.h ，所以你对问题 2 的前提(即 strbuf.c 不包括 strbuf.h )是错误的:它确实包括它，只是不直接。
extern应用于函数
extern函数声明从不需要关键字，但它确实有作用:它声明命名函数的标识符(即函数的名称)与任何先前可见的声明具有相同的链接，或者如果没有这样的声明可见，则标识符具有外部链接。这种相当令人困惑的措辞实际上意味着，鉴于:

static int foo(void); extern int foo(void);

foo的第二次声明还声明它 static ，给它内部链接。如果你写:

static int foo(void); int foo(void); /* wrong in 1990s era C */

您首先将其声明为具有内部链接，然后声明为具有外部链接，并且在 1999 年之前的 C,1 版本中会产生未定义的行为。从某种意义上说， extern关键字增加了一些安全性(以混淆为代价)，因为它可能意味着 static必要时。但是你总是可以写 static再次，和 extern不是 Elixir :

extern int foo(void); static int foo(void); /* ERROR */

这第三种形式仍然是错误的。第一 extern声明之前没有可见的声明，所以 foo有外联，然后第二个 static声明给出 foo内部链接，产生未定义的行为。

总之， extern在函数声明中不需要。有些人只是出于风格原因更喜欢它。

(注意:我在 C99 中遗漏了 extern inline，这有点奇怪，而且实现也各不相同。有关更多详细信息，请参阅 http://www.greenend.org.uk/rjk/2003/03/inline.html。)
extern应用于变量声明
extern变量声明上的关键字有多种不同的效果。首先，与函数声明一样，它会影响标识符的链接。其次，对于任何函数之外的标识符(两种通常意义上的“全局变量”之一)，它会导致声明成为声明，而不是定义，前提是变量也没有被初始化。

对于函数内部的变量(即具有“块作用域”)，例如 somevar在:

void f(void) {
    extern int somevar;
    ...
}

extern关键字导致标识符具有一些链接(内部或外部)而不是“无链接”(对于自动持续时间局部变量)。在这个过程中，它也导致变量本身具有静态持续时间，而不是自动的。 (自动持续时间变量从不具有链接，并且始终具有块作用域，而不是文件作用域。)

与函数声明一样，链接 extern如果之前有一个可见的内部链接声明，assigns 是内部的，否则是外部的。所以 x内 f()这里有内部联系，尽管 extern关键词:

static int x;
void f(void) {
    extern int x; /* note: don't do this */
    ...
}

写这种代码的唯一原因是为了迷惑其他程序员，所以不要这样做。 :-)

通常，使用 extern 注释“全局”(即文件范围、静态持续时间、外部链接)变量的原因关键字是为了防止该特定声明成为定义。使用所谓的“def/ref”模型的 C 编译器在多次定义相同名称时会在链接时消化不良。因此，如果 file1.c说 int globalvar;和 file2.c还说 int globalvar; , 两者都是定义，代码可能无法编译(尽管大多数类 Unix 系统默认使用所谓的“通用模型”，这使得它无论如何都能工作)。如果你在头文件中声明了这样一个变量——它很可能包含在许多不同的 .c 中。文件—使用 extern使该声明“只是一个声明”。

其中之一，也是唯一一个 .c然后文件可以再次声明该变量，而忽略 extern关键字和/或包括初始化程序。或者，有些人更喜欢头文件使用这样的样式:

/* foo.h */
#ifndef EXTERN
# define EXTERN extern
#endif
EXTERN int globalvar;

在这种情况下，其中一个(并且只有一个) .c文件可以包含序列:

#define EXTERN
#include "foo.h"

在这里，由于 EXTERN已定义， #ifndef关闭后续 #define和线路 EXTERN int globalvar;扩展到只是 int globalvar;以便这成为定义而不是声明。就我个人而言，我不喜欢这种编码风格，尽管它确实满足了“不要重复自己”的原则。大多数情况下，我发现大写 EXTERN误导，这种模式对初始化没有帮助。喜欢它的人通常会添加第二个宏来 stash 初始值设定项:

#ifndef EXTERN
# define EXTERN extern
# define INIT_VAL(x) /*nothing*/
#else
# define INIT_VAL(x) = x
#endif

EXTERN int globalvar INIT_VAL(42);

但是当要初始化的项目需要复合初始化器(例如，应该初始化为 struct 的 { 42, 23, 17, "hike!" } )时，即使这样也会崩溃。

(注意:我在这里故意掩盖了整个“暂定定义”的事情。没有初始化器的定义只是“暂定定义”直到翻译单元结束。这允许某些类型的前向引用，否则太困难来表达。通常不是很重要。)

包括声明函数的头文件 f在定义函数的代码中 f
这总是一个好主意，原因很简单:编译器会比较 f() 的声明。在标题中反对 f() 的定义在代码中。如果两者不匹配(出于任何原因——通常是初始编码中的错误，或者在维护期间未能更新两者之一，但偶尔只是由于 Cat Walked On Keyboard Syndrome 或类似的原因)，编译器可以捕获错误在编译时。

11999 年的 C 标准说省略了 extern函数声明中的关键字与使用 extern 的含义相同关键字那里。这更容易描述，并且意味着您得到定义(和明智)的行为而不是未定义的(因此可能是好的可能是坏的行为)。