为什么标准 C 库具有多个头文件，而不是将内容合并到单个头文件中？ [已关闭]

Question

为什么标准C库需要多个头文件？将其合并到一个头文件中不是更方便用户使用吗？

我知道没有必要包含未使用的函数原型/全局变量，但是，如果这些未使用的引用，编译器最终不会删除它们吗？

也许我低估了所有头文件的内容大小。但似乎我总是在谷歌上搜索以找出我需要 #include 的标头。

编辑：最上面的评论引用了 50MB 的大小，这似乎不真实。与其他语言的标准库相比，C 库相对简洁，因此产生了问题。

Answer 1

// 讽刺开启

构建您自己的

#include "monster.h"

，其中包含您想要从集合中获得的所有内容。

人们总是编写混淆的代码。但是，你不会受到你的同伴的欢迎。

// 讽刺关闭

真正的原因是？当存储刚刚超越打孔卡技术时，C 就被开发出来了。多用户系统可能有 1/2Mb 的（磁）核心内存和现在可笑的循环时间。

然而，大量的 C 代码被开发出来（UNIX 流行的故事众所周知。）

虽然新标准可以改变细节（C++已经改变了），但是有大量的代码可能/将不再能够被编译。

查找“传统”。

世界上有（太多）代码示例，其中通常的集合（例如 stdio.h、stdlib.h 等）已“隐藏”在

#include "myApp.h"

中。这样做会迫使读者寻找第二个文件来验证 &^%&%& 正在发生什么。

习惯了。如果这是一种不好的做法，它就不会存在约 50 年。

---

出于类似的原因，“函数”被“分组”到不同的库中。通过扩展，池化这些库可能会让事情稍微“不那么混乱”，但链接过程可能需要超级计算机在截止时间之前完成工作。

---

振作起来。清晰编写的 C++ 代码通常有一个

.h

和

.cpp

来表示应用程序中使用的 每个 类。有时，“家庭”（层次结构）可能会共同生活在一对文件中，尽管当编码员遇到糟糕的一天时，这可能会导致“嘘嘘”。这些应用程序的编码人员在设计第一个具有多重继承的 class 时开始出现 神经崩溃 。