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