c - 包含在头文件中

Question

头文件应该有 #include是吗？

我一般认为这种分层包含是不好的。假设你有这个:

foo.h:

#include <stdio.h> // we use something from this library here
struct foo { ... } foo;

主.c

#include "foo.h"
/* use foo for something */
printf(...)

那天 main.c 的实现发生变化，您不再使用 foo.h，编译将中断，您必须添加 <stdio.h>手工制作。

与拥有这个相比:

foo.h

// Warning! we depend on stdio.h
struct foo {...

主.c

#include <stdio.h> //required for foo.h, also for other stuff
#include "foo.h"

当你停止使用 foo 时，删除它不会破坏任何东西，但删除 stdio.h 会破坏 foo.h。

.h 文件中是否应该禁止#includes？

Answer 1

您已经概述了关于这个主题的两个主要哲学。

我个人的观点(我认为这是人们对此真正拥有的全部)是 header 应尽可能独立。我不想知道 foo.h 的所有依赖关系只是为了能够使用该 header 。我也鄙视必须以特定顺序包含 header 。

但是，foo.h 的开发者还应负责使其尽可能不受依赖。例如，foo.h标题应该写成不依赖于stdio.h如果可能的话(使用前向声明可以帮助解决这个问题)。

请注意，C 标准禁止标准 header 包含另一个标准 header ，但 C++ 标准不这样做。因此，您可以看到从一个 C++ 编译器版本迁移到另一个版本时所描述的问题。例如，在 MSVC 中，包括 <vector>用来带进来<iterator> ，但在 MSVC 2010 中不再出现，因此之前编译的代码可能不再存在，因为您可能需要专门包含 <iterator> .

但是，尽管 C 标准似乎提倡第二种哲学，但请注意，它还要求没有 header 依赖于另一个 header ，并且您可以按任何顺序包含 header 。因此，您可以两全其美，但代价是 C 库的实现者变得复杂。他们必须跳过一些障碍才能做到这一点(特别是为了支持可以通过多个 header 中的任何一个引入的定义，例如 NULL 或 size_t )。我猜起草 C++ 标准的人决定将复杂性添加到模仿者中不再合理(我不知道 C++ 库实现者在多大程度上利用了“漏洞”——看起来 MS 可能正在加强这一点，即使技术上不需要)。