简单地包含所有头文件是否正确？答案

【问题标题】：Is it right to simply include all header files?简单地包含所有头文件是否正确？
【发布时间】：2011-11-12 00:41:25
【问题描述】：

记住系统头文件的名字很痛苦……

有没有办法一次包含所有现有的头文件？

为什么没有人这样做？

【问题讨论】：

如果这是个好主意 - 整个语言只有 1 个头文件
如果很难记住，您可以使用 eclipse 及其“添加包含”功能。
当然“有办法”。但这不是一个好主意。或许更有经验的 C 程序员只是知道他们的依赖关系在哪里声明，并且只包含他们需要的东西。
我认为这是一个非常糟糕的主意！
@AdrianCornish IIRC，一个非常早期的 pre-STL C++ 标准库草案就是这样...... 包含所有 C++ 头文件的头文件。然后在理智的情况下，他们摆脱了它......以及草案的其余部分，并从 STL 重新开始。

标签： c

【解决方案1】：

包含不需要的头文件是一种非常糟糕的做法。减慢编译速度的问题可能很重要，也可能无关紧要；更大的问题是它隐藏了依赖关系。您包含在源文件中的头文件集应该是模块所依赖的功能的文档，并且与外部文档或 cmets 不同，编译器会自动检查其完整性（未包含所需的头文件将导致错误）。确保不存在不需要的依赖项不仅可以提高可移植性；它还可以帮助您跟踪不需要的和潜在危险的交互，例如，应该是纯计算或纯数据结构管理的模块正在访问文件系统的情况。

无论标头是标准系统标头还是您自己的程序或第三方库中的模块标头，这些原则都适用。

【讨论】：

【解决方案2】：

您的源代码文件在编译器查看它们之前已被预处理，#include 语句是预处理器使用的指令之一。在进行预处理时，#include 语句将替换为包含的文件的全部内容。包含所有系统文件的结果将是编译器需要处理的非常大的源文件，这将在编译期间花费大量时间。

【讨论】：

【解决方案3】：

没有人包含所有头文件。太多了，其中有几个是和其他文件互斥的（比如ncurses.h和curses.h）。

即使从头开始编写程序，也确实没有那么糟糕。有几个很容易记住：stdio.h 表示任何FILE 的东西； ctype.h 用于任何字符分类，alloc.h 用于任何 malloc() 的使用，等等。

如果你不记得一个：

离开#include
编译
检查前几条错误消息以查找是否缺少头文件，例如某些类型未声明，或调用具有假定参数类型的函数
找出原因是哪个函数调用
查看该函数的手册页（或编译器拥有的任何文档）
注意文档中显示的#include 并添加它
重复直到所有错误都修复

添加到现有代码库要容易得多。您可以工作数百或数千小时，而无需添加#include。

【讨论】：

【解决方案4】：

不，这是一个糟糕的主意，并且会大大增加您的编译时间，并可能通过包含大量未使用的代码使您的 exe 变得更大。

【讨论】：

这应该对 exe 大小没有任何影响。
@Oli - 可能对 C 来说是正确的 - 我在想更多的 C++ 可以生成大量额外的模板代码。

【解决方案5】：

我知道你在说什么，但我需要仔细检查我正在使用的函数的函数原型（无论如何，对于那些我不每天使用的函数）——我只是复制和粘贴#includes 直接来自相关功能的联机帮助页。我已经在看联机帮助页了（在vim(1) 中是一个简单的K），所以感觉不会是额外的负担。

【讨论】：

【解决方案6】：

您可以创建一个“主”标头，将所有包含项放入其中。然后在其他所有内容中包括它！当心定义冲突和循环引用...所以.... Master1.h, master2.h, ...

不提倡。只是说说而已。

【讨论】：