带有所有必要#include语句的单头文件

我目前正在使用大量源文件编写程序。有时很难跟踪我已经拥有的库d。理论上，我可以创建一个名为Headers.h的头文件，它只包含我需要的所有#include语句，然后将所有其他头文件#include "Headers.h"。带有所有必要#include语句的单头文件

为什么这是一个好/坏主意？

2014-12-05 abalabazn

的#include利弊<比特/ STDC++。H>包含大部分的库...我不知道它是否包含所有库... – Mukit09 2014-12-05 04:31:10

假设一些模块evil.c需要evil.h，它重新定义了innocent.c中使用的一堆符号，也包含内联函数定义，还有一些巨大的静态数组声明可以很好的衡量。你真的想在项目中的其他模块中包含evil.h吗？ – 2014-12-05 04:34:22

这个想法的好处在于它与Microsoft的预编译头文件非常兼容。不幸的是，每个地方通常都包含许多你不需要或想要的东西。 – 2014-12-05 04:55:13

优点：

缺点：

定义中包含的文件可能互相冲突。特别是在没有命名空间的C中（用C和C++标记）
特别是宏可能会导致难以调试的问题，其中宏定义意外地与文件中的某个名称冲突或其他包含的文件之一
根据您使用的编译器，编译时间可能会缩短。如果使用预编译头文件的编译器，它实际上可能会缩短编译时间，但如果不是相反的话会发生
您经常会不必要地触发重建文件。如果你的编译系统设置正确，那么如果任何包含的文件被修改，每个源文件都将被重建。如果您始终在项目中包含所有标题，则对标题的更改将强制重新编译所有源文件。不太可能成为系统头文件的问题，但如果您也将自己的头文件包含在主文件中，那将是一个问题。

总的来说，我不会推荐这种方法。上面列出的最后一个con特别重要。

最佳做法是只包含每个文件中代码所需的标题。

2014-12-05 05:38:06 harmic

作为Harmic's answer的补充，确实主要的问题是编译系统（大多数编译器都是在文件时间戳上工作，而不是在文件内容上工作，omake是一个值得注意的例外）。

请注意，如果你只关心很多依赖，GNU make可以用autodependencies使用，传递给GCC -M*选项（即以g++，实际上给预处理器）在一起。

然而，许多库提供给他们的用户的单个报头（例如<gtk/gtk.h>）

另外，一个头文件是更友好的预编译头技术。特别是，GCC wants a single header for precompilation。请参阅ccache。

2014-12-05 06:00:56

追踪所有需要的包括将更加困难，因为它们是从它们的C源文件提取并没有真正支撑模块化脓所有从#harmic

2014-12-07 04:12:43 crypticfool

回答