C++：在头文件中包含类定义答案

【问题标题】：C++: including a class definition in a header fileC++：在头文件中包含类定义
【发布时间】：2014-01-28 07:29:37
【问题描述】：

许多帖子非常坚持源代码不应放在标头中，并且应将标头文件保持在最低限度。我一直坚持使用自己的代码，但我想使用其他人的代码来实现特定目标（代码记录在此处http://ftp.arl.mil/random/）。

我注意到这基本上是一个定义类的巨大头文件。可以把它留在头文件中吗？我应该将其全部复制到 .cpp 文件并创建一个仅声明函数、结构等的新 .h 吗？

如果我按照我的建议将其拆分为 .cpp 和 .h，它会起作用吗？还是类需要在所有源代码访问的标头中？

【问题讨论】：

分发巨型头文件的重点是不必链接库/cpp 文件。用户可以包含文件一次，使用它并完成它。我想如果这是一个 tar.gz 文件并且您必须在使用它之前对其进行编译，那将是一件很痛苦的事情。它与您在应用程序中处理头文件/cpp 文件的方式不同。
将源代码放在头文件中是有原因的。有理由不这样做。您应该了解这些问题，而不是试图遵循任意规则。
我不推荐它，除非在某些情况下，一个类只有一个 .h 会很酷。但我通常使用inline 来完成这项工作。有一些很好的教程可以理解为什么将所有内容都放在标题中。检查this问题以获取信息。

标签： c++ class header

【解决方案1】：

需要在多个 cpp 文件中看到的声明（说明存在）应该放在头文件中。单个 cpp 文件的本地声明应该在 cpp 文件本身中。

定义（提供函数体或分配/初始化变量）通常应该放在 cpp 文件中，但并非总是如此。

您需要了解的问题是，如果编译器看到的是头文件而不是相应的 cpp 文件，它是否有足够的信息来完成它的工作。

例如：如果编译器已经看到声明（方法原型），您可以调用方法 -- 除非该方法是泛型的（模板化方法或模板化类的成员）或内联，在这种情况下编译器需要也看到了定义（方法体）。

因此，普通方法放在 cpp 文件中；模板化的方法放在头文件中；内联方法进入头文件（等等）。

在其他情况下，定义属于头文件，包括静态成员常量。一方面，这一切都归结为为编译器提供了它需要的信息，另一方面是最小化单独的可编译单元之间的耦合。同样，没有硬性规定，只有指导方针以及编写代码的开发人员的知识和经验。

【讨论】：

并非所有声明都应该放在标题中。并非所有定义都应该放在源文件中。抱歉，我就是不能同意你的看法。
但我可以同意你的看法。除了了解编译过程的工作原理之外，没有硬性规定。我将编辑“标题中的声明”子句，使其成为您可能同意的内容..
谢谢，我同意。 +1

【解决方案2】：

.h 文件通常在许多 .cpp 文件之间共享。全局变量和函数代码不应该在头文件中，因为它会在链接过程中产生重复。

在头文件中可以使用常量、定义、函数头和类声明。您不必多次声明同一事物，并且可以在 .cpp 文件之间共享定义。

【讨论】：

【解决方案3】：

源代码不应该放在头文件中，而头文件应该是保持在最低限度。

这是一个流行的断言，虽然它通常可能不是坏的建议，但你不应该从中得出绝对的结论。有时标题应该是最小的并且不包括定义。有时情况正好相反。您会选择其中一种是有原因的，但“人们说”不是其中之一。

考虑 C++ 标准库。更好的是，考虑 Boost。一些著名的 C++ 专家表示，Boost 是历史上设计最完善的 C++ 库。但是，如果您查看这些库，您会发现它们基本上只是大部分的巨型头文件。这如何与“他们”所说的相协调？

重点是：您必须了解某些文件按原样设计的原因，并对每种情况下的正确与错误做出自己的判断。

我是否应该将其全部复制到 .cpp 文件并创建一个新的 .h 声明函数、结构等？

我会说可能不会。对我来说，这听起来像是维护噩梦的秘诀。我的第一个直觉是按照图书馆作者打算使用的方式使用 3rd 方库。这样您就不会脱离支持网格，也不会引入一组新的复杂情况，您将完全靠自己来解决。除非您有特定的、可证明的理由来更改库的体系结构，否则不要这样做。 “他们说”对我来说不是一个足够好的理由。

【讨论】：