不幸的是，您可能使用了错误的语言。当您将类定义与实现分开时，有些事情在 C++ 中要容易得多。即使使用前向声明，您可能仍然会遇到只能通过将实现移动到单独文件中来解决的循环依赖关系。
如果您想编写惯用的 Java，只需用 Java 编写即可。不幸的是，如果您想使用 C++ 语言，您将不得不在其约束范围内工作。
假设每个类都有一个 .hpp 文件，那么包含图类似于类依赖图。为了可重用性，类依赖图应该是非循环的（您可以通过使用接口来“拆分”循环来实现这一点）。所以，我想包含图也应该是非循环的。
至于#include 子句，恐怕您必须手动编写它们。但是如果你的类足够小，这应该不是问题（如果你的类太大，你无法弄清楚你需要什么，那么你就有了设计问题）。
就像一个小提示一样，将类拆分为.cpp文件.h不仅可以解决循环依赖问题，而且还可能会大大增加编译时间。
如果您尝试编写仅包含标头的代码，那么即使一小部分代码被更改，您最终也可能会完全重建您的项目。
仅当您设计基于模板的库时，仅标头代码才有意义，基本上，因为模板应该驻留在标头中。参见boost template library，例如。还要提一下，使用模板库的实际应用程序仍然具有.cpp用于其代码的这些文件，这就是实际“使用”实例化模板的地方。
我强烈建议将实现放入“.cpp”文件中，并将声明或接口放入头文件“.hpp”中。
当头文件中的内联函数发生更改时，将重新编译包含该头文件的所有源文件。当源文件中的函数发生变化时，只需要重新编译源文件。
在创建内联函数之前让代码正确且稳健地工作。
另一个建议是为按主题分组或不经常编译的源文件创建库（目标文件的集合）（即它们可以工作并且不会更改）。
不要担心文件的数量或构建过程的长度。专注于正确、稳健和按计划完成项目。根据需要调整构建过程。如果计划中有很多时间，代码工作正常且健壮，则进行更改。如果更改构建过程可以“显着”加快开发时间，那么进行更改。
