只是一个风格问题...
我是一名独立工作的独立游戏开发者，我养成了在标题中编写整个类的“坏”习惯。我知道 .h/.cpp 文件组合的一些好处是它们允许将代码分割成编译块，只要它们保持不变就不需要重新编译。并允许将接口与实现分开。
然而，这些事情对我来说都没有任何好处，因为我倾向于将我的实现放在我可以轻松改进、更改、阅读的地方。我的编译时间几乎是瞬时的（2-4 秒，如果我将 SFML 或 Box2D 更新到最新版本并且它们也需要重新编译，则需要 15 秒）
我认为这样的编码为我节省了大量时间，而且由于文件较少，我的代码对我来说不那么“难以承受”。
但鉴于此，一般而言，对于编译时间和接口/实现分离不是优先事项的小型项目，是否有任何令人信服的理由为每个“file.h”设置遵循“file.cpp”？
对于编译时间和接口/实现分离不是优先事项的小项目，是否有任何令人信服的理由要遵循每个“file.h”设置的“file.cpp”？
没有;在头文件中定义类和函数没有任何问题，尤其是在不关心编译时间的小型项目中。
就其价值而言，我当前正在进行的爱好项目有 33 个头文件和一个 .cpp 文件（不包括单元测试）。不过，这很大程度上是因为几乎所有东西都是模板。
如果您有一个巨大的软件项目，或者需要将代码封装到库中并且实际上需要模块化，那么将代码从头文件中分离出来可能是有意义的。如果您想隐藏一些实现细节（例如，如果您有一些丑陋的标头，您不想将其包含在项目的其他位置 - 例如 WinAPI 标头），那么将代码拆分到单独的源文件中是有意义的隐藏这些细节。否则，可能只是付出了很多努力却没有得到很多收获。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
