我想查看真实世界应用程序的源代码以了解良好的编程实践等。所以我选择了 Git 并下载了 1.8.4 版的源代码。
在随机浏览各种文件后,这两个文件引起了我的注意:strbuf.h strbuf.c
这两个文件显然用 this documentation 定义了一个 API。 .
我有两个问题:
作为一名新手程序员,我一直都知道你在 .c 文件中编写函数定义,而函数声明、宏、内联等编写在 .h 文件中,然后 #included 在每个想要使用这些的 .c 文件中功能等
任何人都可以解释一下吗?
最佳答案
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
的含义相同关键字那里。这更容易描述,并且意味着您得到定义(和明智)的行为而不是未定义的(因此可能是好的可能是坏的行为)。
关于c - 为什么某些声明为 extern 的函数和头文件未包含在 Git 源代码的源代码中?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18171373/