优点与优点 将所有代码放入 C++ 头文件中的缺点？

Question

您可以构造一个 C++ 程序，以便（几乎）所有代码都驻留在头文件中。 它本质上看起来像一个 C# 或 Java 程序。 但是，您确实需要至少一个 .cpp 文件来在编译时引入所有头文件。 现在我知道有些人绝对会讨厌这个想法。 但我还没有发现这样做有任何令人信服的缺点。 我可以列出一些优点：

[1] 编译时间更快。 所有头文件只解析一次，因为只有一个 .cpp 文件。 另外，一个头文件不能包含多次，否则您将遇到构建中断。 使用替代方法时，还有其他方法可以实现更快的编译，但这非常简单。

[2] 它通过使它们绝对清晰来避免循环依赖。 如果ClassA.h中的ClassA对ClassB.h中的ClassB有循环依赖，我必须放置一个前向参考和 它很突出。 （请注意，这与 C# 和 Java 不同，编译器会自动解决循环依赖关系。在我看来，这会鼓励不良的编码实践）。 同样，如果您的代码位于 .cpp 文件中，则可以避免循环依赖，但在实际项目中，.cpp 文件往往会包含随机标头，直到您可以'搞不清谁依赖谁。

你的想法？

Answer 1

原因 [1] 更快的编译时间

不在我的项目中：源文件 (CPP) 仅包含它们需要的标头 (HPP)。 因此，当我因为一个微小的更改而只需要重新编译一个 CPP 时，未重新编译的文件数量是原来的十倍。

也许你应该用更逻辑的源代码/标题来分解你的项目：A类实现的修改不需要重新编译B、C、D、E等的实现。

原因[2]它避免了循环依赖

循环依赖在代码中？

抱歉，但我还没有将此类问题视为真正的问题：假设 A 依赖于 B，而 B 依赖于 A：

struct A
{
   B * b ;
   void doSomethingWithB() ;
} ;

struct B
{
   A * a ;
   void doSomethingWithA() ;
} ;

void A::doSomethingWithB() { /* etc. */ }
void B::doSomethingWithA() { /* etc. */ }

解决该问题的一个好方法是将这个源分解为至少一个源/每个类的标头（与 Java 方式类似，但每个类有一个源和一个标头）：

// A.hpp

struct B ;

struct A
{
   B * b ;
   void doSomethingWithB() ;
} ;

.

// B.hpp

struct A ;

struct B
{
   A * a ;
   void doSomethingWithA() ;
} ;

。

// A.cpp
#include "A.hpp"
#include "B.hpp"

void A::doSomethingWithB() { /* etc. */ }

。

// B.cpp
#include "B.hpp"
#include "A.hpp"

void B::doSomethingWithA() { /* etc. */ }

因此，不存在依赖性问题，并且编译时间仍然很快。

我错过了什么？

当从事“现实世界”项目时

在现实世界的项目中，cpp 文件往往包含随机标头，直到您无法弄清楚谁依赖于谁

。当然。 但是，如果您有时间重新组织这些文件来构建您的“one CPP”解决方案，那么您就有时间清理这些标头。 我的标头规则是：

• 分解标头，使它们尽可能模块化
• 永远不要包含不需要的标头
• 向前声明它
• 如果您需要一个符号，只有在上述失败时才

，包括标头无论如何，所有标头都必须是 self -sufficient，这意味着：

• 一个标头包括所有需要的标头（并且仅需要标头 - 参见上文）
• 一个包含一个标头的空 CPP 文件必须编译而无需包含其他任何内容

这将消除排序问题和循环依赖。

编译时间是一个问题吗？ 那么...

如果编译时间真的是一个问题，我会考虑：

• 使用预编译头（这对于 STL 和 BOOST 非常有用）
• 通过 PImpl 习惯用法减少耦合，如 http://en.wikipedia.org/wiki/Opaque_pointer
• 使用网络共享编译

结论

您所做的并不是将所有内容都放入标头中。

您基本上将所有文件包含到一个且唯一的最终源中。

也许您在完整项目编译方面获胜。

但是当编译一个小的改变时，你总是会失败。

在编码时，我知道我经常编译一些小的更改（如果只是为了让编译器验证我的代码），然后最后一次进行完整的项目更改。

如果我的项目按照您的方式组织，我会损失很多时间。

Answer 2

我不同意第 1 点。

是的，只有一个 .cpp，并且从头开始的构建时间更快。 但是，您很少从头开始构建。 您进行一些小的更改，并且每次都需要重新编译整个项目。

我更喜欢用另一种方式来做：

• 在 .h 文件中保留共享声明
• 保留仅在 .cpp 文件中的一个位置使用的类的定义

因此，我的一些 .cpp 文件开始看起来像 Java 或 C# 代码；）

但是， “将内容保留在 .h 中” 方法在设计系统时很好，因为您提出了第 2 点。 我通常在构建类层次结构时这样做，然后当代码体系结构变得稳定时，我将代码移动到 .cpp 文件。

Answer 3

你说你的解决方案有效是对的。 它甚至可能对您当前的项目和开发环境没有缺点。

但是...

正如其他人所说，将所有代码放入头文件中会在每次更改一行代码时强制进行完整编译。 这可能还不是问题，但您的项目可能会变得足够大，以至于编译时间将成为一个问题。

另一个问题是共享代码时。 虽然您可能还没有直接关心，但对代码的潜在用户隐藏尽可能多的代码非常重要。 通过将代码放入头文件中，任何使用您的代码的程序员都必须查看整个代码，而只对如何使用它感兴趣。 将代码放入 cpp 文件中只允许提供二进制组件（静态或动态库）及其接口作为头文件，这在某些环境中可能更简单。

如果您希望能够将当前代码转换为动态库，这就是一个问题。 由于您没有与实际代码分离的正确接口声明，因此您将无法将编译后的动态库及其使用接口作为可读头文件提供。

您可能还没有这些问题，这就是为什么我告诉您您的解决方案在您当前的环境中可能没问题。 但最好为任何变化做好准备，其中一些问题应该得到解决。

PS：关于C#或Java，你应该记住，这些语言并没有按照你所说的去做。 它们实际上是独立编译文件（如cpp文件）并为每个文件全局存储接口。 然后，这些接口（以及任何其他链接的接口）用于链接整个项目，这就是它们能够处理循环引用的原因。 由于 C++ 每个文件只执行一次编译，因此它无法全局存储接口。 这就是为什么您需要将它们明确地写入头文件中。

Answer 4

对我来说，明显的缺点是您总是必须立即构建所有代码。 使用 .cpp 文件，您可以进行单独编译，因此您只需重建真正发生更改的部分。

Answer 5

您误解了该语言的用途。 .cpp 文件实际上（或者应该是除了内联代码和模板代码之外）系统中唯一的可执行代码模块。 .cpp 文件被编译成目标文件，然后链接在一起。 .h 文件仅用于前向声明 .cpp 文件中实现的代码。

这会带来更快的编译时间和更小的可执行文件。 它看起来也相当干净，因为您可以通过查看其 .h 声明来快速了解您的类。

至于内联代码和模板代码 - 因为它们都用于由编译器而不是链接器生成代码 - 它们必须始终可供每个 .cpp 文件的编译器使用。 因此，唯一的解决方案是将其包含在您的 .h 文件中。

但是，我开发了一个解决方案，其中我的类声明在 .h 文件中，所有模板和内联代码在 .inl 文件中，所有非模板/内联代码的实现在我的 .cpp 文件中。 .inl 文件 #included 在我的 .h 文件的底部。 这使事情保持干净和一致。

Answer 6

您的方法的一个缺点是您无法进行并行编译。 您可能认为现在编译速度更快，但如果您有多个 .cpp 文件，您可以在自己计算机上的多个内核上并行构建它们，或者使用 distcc 或 Incredibuild 等分布式构建系统。

Answer 7

您可能想查看Lazy C++。 它允许您将所有内容放在一个文件中，然后在编译之前运行并将代码拆分为 .h 和 .cpp 文件。 这可能会为您提供两全其美的选择。

编译时间缓慢通常是由于用 C++ 编写的系统内的过度耦合造成的。 也许您需要将代码拆分为具有外部接口的子系统。 这些模块可以在单独的项目中编译。 这样可以最大限度地减少系统不同模块之间的依赖关系。

Answer 8

我喜欢考虑在接口和实现方面分离 .h 和 .cpp 文件。 .h 文件包含另外一个类的接口描述，.cpp 文件包含实现。 有时，一些实际问题或清晰度会妨碍完全干净的分离，但这就是我开始的地方。 例如，为了清晰起见，我通常在类声明中内联编写小型访问器函数。 较大的函数编码在 .cpp 文件中。

无论如何，不​​要让编译时间决定您将如何构建程序。 最好有一个可读且可维护的程序，而不是 1.5 分钟而不是 2 分钟即可编译的程序。

Answer 9

你要放弃的一件事是匿名命名空间，如果没有它我将很难生活。

我发现它们对于定义特定于类的实用函数非常有价值，这些函数在类的实现文件之外应该不可见。 它们还非常适合保存对系统其他部分不可见的任何全局数据，例如单例实例。

Answer 10

您超出了该语言的设计范围。 虽然你可能会得到一些好处，但它最终会咬你的屁股。

C++ 是为具有声明的 h 文件和具有实现的 cpp 文件而设计的。 编译器就是围绕这个设计构建的。

是的，人们争论这是否是一个好的架构，但这就是设计。 最好将时间花在解决问题上，而不是重新发明设计 C++ 文件架构的新方法。

Answer 11

好吧，正如许多人指出的那样，这个想法有很多缺点，但为了平衡一点并提供一个优点，我想说，将一些库代码完全放在标头中是有意义的，因为它将使其独立于其他库代码 代码

例如，如果尝试使用不同的开源库，则可以将它们设置为使用不同的方法来链接到您的程序 - 有些可能使用操作系统动态加载的库代码，有些可能使用操作系统的动态加载库 设置为静态链接； 有些可能设置为使用多线程，而另一些则不然。 对于程序员来说，尝试解决这些不兼容的方法很可能是一项艰巨的任务，尤其是在时间有限的情况下。

然而，当使用完全包含在标头中的库时，所有这些都不是问题。 对于一个合理且编写良好的库来说，“它确实有效”。

Answer 12

我相信，除非您使用 MSVC 的预编译头，并且您使用 Makefile 或其他基于依赖项的构建系统，否则在迭代构建时拥有单独的源文件应该编译得更快。 因为我的开发几乎总是迭代的，所以我更关心它重新编译我在文件 x.cpp 中所做的更改的速度，而不是我未更改的其他二十个源文件。 此外，我对源文件的更改频率比对 API 的更改频率要高得多，因此它们的更改频率较低。

关于循环依赖。 我会更进一步采纳帕塞巴尔的建议。 他有两个互相有指针的类。 相反，我更频繁地遇到一个类需要另一类的情况。 发生这种情况时，我将依赖项的头文件包含在另一个类的头文件中。 一个例子：

// foo.hpp
#ifndef __FOO_HPP__
#define __FOO_HPP__

struct foo
{
   int data ;
} ;

#endif // __FOO_HPP__

。

// bar.hpp
#ifndef __BAR_HPP__
#define __BAR_HPP__

#include "foo.hpp"

struct bar
{
   foo f ;
   void doSomethingWithFoo() ;
} ;
#endif // __BAR_HPP__

。

// bar.cpp
#include "bar.hpp"

void bar::doSomethingWithFoo()
{
  // Initialize f
  f.data = 0;
  // etc.
}

我之所以包含这个（与循环依赖关系稍微无关），是因为我觉得除了随意包含头文件之外，还有其他选择。 在此示例中，struct bar 源文件不包含 struct foo 头文件。 这是在头文件中完成的。 这样做的优点是，使用 bar 的开发人员不必了解开发人员使用该头文件需要包含的任何其他文件。

Answer 13

标头中的代码的一个问题是它必须内联，否则在链接包含同一标头的多个翻译单元时将会遇到多重定义问题。

最初的问题指定项目中只有一个 cpp，但如果您要创建用于可重用库的组件，则情况并非如此。

因此，为了尽可能创建最可重用和可维护的代码，仅将内联和可内联代码放在头文件中。

Answer 14

面向对象编程的重要理念在于数据隐藏导致封装类的实现对用户隐藏。 这主要是为了提供一个抽象层，类的用户主要使用实例特定类型和静态类型的可公开访问的成员函数。 然后，类的开发人员可以自由修改实际的实现，前提是这些实现不暴露给用户。 即使实现是私有的并在头文件中声明，更改实现也将需要重新编译所有依赖的代码库。 然而，如果实现（成员函数的定义）位于源代码（非头文件）中，则库会发生更改，并且依赖的代码库需要与库的修订版本重新链接。 如果该库像共享库一样动态链接，那么保持函数签名（接口）相同并且实现更改也不需要重新链接。 优势？ 当然。

Answer 15

静态或全局变量的拼凑甚至更不透明，也许无法调试。

例如计算分析的迭代总数。

在我的杂乱文件中，将这些项目放在 cpp 文件的顶部可以很容易地找到它们。

我所说的“也许不可调试”是指我通常会将这样的全局变量放入 WATCH 窗口中。 由于它始终在范围内，因此无论程序计数器现在位于何处，WATCH 窗口始终可以到达它。 通过将此类变量放在头文件顶部的 {} 之外，您可以让所有下游代码“看到”它们。 通过将它们放在 {} 内，如果您的程序计数器位于 {} 之外，我认为调试器将不再将它们视为“范围内”。 而对于 kludge-global-at-Cpp-top，即使它在 link-map-pdb-etc 中显示的范围内可能是全局的，但如果没有 extern 语句，其他 Cpp 文件就无法访问它，避免意外耦合。

Answer 16

没有人提出的一件事是编译大文件需要大量内存。 立即编译整个项目将需要如此巨大的内存空间，即使您可以将所有代码放入标头中也是不可行的。

Answer 17

如果您使用模板类，则无论如何都必须将整个实现放在标头中...

一次性编译整个项目（通过单个基本 .cpp 文件）应该允许诸如“整个程序优化”或“跨项目”之类的内容。模块优化”，仅在少数高级编译器中可用。 如果您将所有 .cpp 文件预编译为目标文件，然后进行链接，那么使用标准编译器实际上不可能实现这一点。

Answer 18

标头中的代码可以方便编码过程。 此外，预编译能力还提高了效率。 一个副作用是，总体二进制大小通常会随着标头中代码量的增加而增加，例如，如果标头跨多个库/可执行文件使用。

然而，C++20 模块是现在的方式：
https://learn.microsoft.com/ en-us/cpp/cpp/modules-cpp?view=msvc-170

引用：

模块消除或减少了许多与
头文件的使用。

使用模块的提示：
https://github。 com/MicrosoftDocs/cpp-docs/blob/main/docs/cpp/tutorial-named-modules-cpp.md

请注意，对于模块（与预编译头不同），在实现文件中包含代码，而不是在模块接口文件，可以有编译时的好处。

关于二进制大小（以 Visual C++ 为例）模块构建生成对象 (.obj) 文件（以及其他文件，例如接口 .ifc 文件），因此二进制大小与接口文件源代码大小的比例问题不大.
https://lists.isocpp.org/sg15/att-1346/C___20_Modules_Build_in_Visual_Studio。 pdf