最近我遇到了以这种方式处理头文件的代码。
会有一个名为global.h的头文件
此global.h将包含一些其他头文件，例如
#include "settings.h"
#include "math.h"
#include "somelibrary.h"
#include "someOtherlibrary.h"
...
现在，只要某个文件想要包括说somelibrary.h，而不是写
#include somelibrary.h它只包含global.h。
所以项目中的每个源文件都有：#include "global.h"
这是避免在每个源文件中编写多个包含的常用方法吗？还有什么其他好处
PS。额外的：如果有人可以解释为什么会有效，那就太好了
答案 0 :(得分：4)
唯一的好处就是容易包括。
缺点是，每次更改头文件时，都必须重新编译所有内容。对于任何大型项目，这都是一个大问题。
它还使删除或更改现有模块变得很痛苦，因为您无法对特定包含进行简单搜索以概述其使用位置。
就是不要这样做。
修改
澄清：如果需要做标题，可以将标题组合在一起。但是我很少需要在实践中这样做;写#include "xxxxx.x"并不太难。
对于包含X，Y和Z的整个应用程序，有一个包含所有内容的标题是不行的。
答案 1 :(得分：3)
这是一种常用的坏做法。如果使用global.h，则会在该文件与项目中的每个模块之间创建紧密耦合，从而在项目的每个模块之间创建紧密耦合。
这是非常糟糕的OO设计！您希望每个模块都是自治的，并且只依赖于对其自身功能至关重要的其他模块。此外，您总是希望设计模块，以便它们可以在多个项目中使用。
例如，如果我想使用您已经为特定项目开发的通用数学库模块，那么为什么您还要强迫我包含该项目中的所有其他不相关文件？
至于＆＃34;避免在每个源文件中写入许多包含＆＃34; ...如果不能在文件顶部写入5-10个非常短的文本行可能是一个主要内容程序员的障碍。显然有很多人发现这是一个障碍，因此他们决定改变整个程序设计。如果你不想在键盘上打字，那么也许不会去寻找程序员的职业生涯。
答案 2 :(得分：1)
编辑：此答案指的是包含文件来自不同项目的情况
只要包含文件引用其他项目或库（而不是同一项目的头文件），我就称之为理顺包含文件的合理方法。借助Microsoft Compilers的“预编译头”支持，这样做甚至可以带来很大的性能优势。它还确保您始终以相同的顺序包含标题，因为如果两个包含内部相互依赖，这有时会导致奇怪的错误。
为MSVC创建所谓的“标准包含头”的首选方法是拥有一个文件（通常名为“stdafx.h”），其中包含项目将要使用的所有库的头文件，即windows .h，math.h，io.h或string。使用正确的编译器设置，“stdafx.h”中提到的所有包含仅对整个项目处理一次。由于这些文件几乎没有变化，因此更改它们需要重建整个项目的事实不是问题。但#include "stdafx.h" 行必须是每个c或cpp文件中的第一行。 ASFAIK，gcc没有相应的。