c++ - 将 C++ 定义放在头文件中是一种好习惯吗？

Question

我个人的 C++ 风格总是将类声明放在包含文件中，将定义放在 .cpp 文件中，非常类似于 Loki's answer to C++ Header Files, Code Separation 中的规定。 .诚然，我喜欢这种风格的部分原因可能与我多年来为 Modula-2 和 Ada 编写代码有关，它们的规范文件和正文文件都有类似的方案。

我有一个同事，他比我更懂 C++，他坚持所有 C++ 声明都应该尽可能在头文件中包含定义。他并不是说这是一种有效的替代风格，或者甚至是更好的风格，而是说这是现在每个人都在 C++ 中使用的新的普遍接受的风格。

我不像以前那样灵活了，所以在我看到更多人和他在一起之前，我并不急于 catch 他的这股潮流。那么这个成语到底有多普遍呢？

只是为了给答案一些结构:现在是 The Way™，非常常见，有点常见，不常见还是疯狂的错误？

Answer 1

你的同事错了，通常的做法是并且一直是把代码放在 .cpp 文件(或任何你喜欢的扩展名)中，并在标题中声明。

有时将代码放在头文件中是有好处的，这可以让编译器进行更巧妙的内联。但与此同时，它会破坏您的编译时间，因为每次编译器包含所有代码时都必须对其进行处理。

最后，当所有代码都是标题时，循环对象关系(有时是需要的)通常很烦人。

归根结底，你是对的，他是错的。

编辑:我一直在考虑你的问题。有一个案例，他说的是真的。模板。许多较新的“现代”库(例如 boost)大量使用模板，并且通常是“仅标题”。但是，只有在处理模板时才应该这样做，因为这是处理模板时的唯一方法。

编辑:有些人想要更清楚一点，这里有一些关于编写“仅标题”代码的缺点的想法:

如果你四处搜索，你会看到很多人在处理 boost 时试图找到一种减少编译时间的方法。例如:How to reduce compilation times with Boost Asio ，其中包含一个 1K 文件的 14 秒编译，其中包含 boost。 14 秒似乎没有“爆炸式增长”，但它肯定比典型的要长得多，并且在处理大型项目时可以很快加起来。仅 header 库确实以可衡量的方式影响编译时间。我们只是容忍它，因为 boost 非常有用。

此外，有很多事情不能仅在 header 中完成(即使 boost 具有您需要链接到某些部分的库，例如线程、文件系统等)。一个主要的示例是，您不能在仅 header 库中拥有简单的全局对象(除非您求助于单例的可恶)，因为您将遇到多个定义错误。 注意: C++17 的内联变量将使这个特定示例在未来变得可行。

最后一点，当使用 boost 作为仅 header 代码的示例时，经常会遗漏一个巨大的细节。

Boost 是库，而不是用户级代码。所以它不会经常改变。在用户代码中，如果你把所有东西都放在头文件中，每一个小改动都会导致你不得不重新编译整个项目。这是对时间的巨大浪费(对于不会从编译到编译的库来说，情况并非如此)。当您在 header /源和更好的情况下拆分内容时，使用前向声明来减少包含，您可以节省一天内重新编译的时间。