将标题放在项目的"include"子目录中有什么好处吗？

以这种方式构建代码通常更容易，尤其是当您要将其导出为带有预编译库的API时。(公共)头然后成为您的API，将它们保存在与源代码分开的地方是有意义的，因为这是必须与库一起分发的代码部分。

可用选项为

• module/*.{cpp,h}-最好用于相关文件的空间位置，最坏的情况是需要应用严格的API焦点(向后兼容性、版本与补丁等)
• module/{include/*.h, src/*.{cpp,h}}-适用于API焦点，适用于空间局部，我的首选
• include/module/*.h,src/module/*.{cpp,h}-最适合API焦点，对空间局部性不是很好

没有真正的利弊，一般来说也没有。在设计API时(与应用程序相比)，您必须在库中提供一组包含，而这种特殊的头文件使开发人员选择将它们与文件系统中的源文件分离的解决方案。

我不认为一个组织比另一个更好，但我可以给你两个建议，帮助你决定什么对你的项目最有利：

• 尽量简化文件层次结构。当涉及到项目配置、安装脚本和版本控制时，嵌入较少的文件夹就不那么麻烦了。

• 最重要的不是头文件的位置，而是它们的包含方式:

  • <>或">
  • 从内部源文件还是从使用您的头的外部代码
  • 是否使用指向它们的路径或直接使用文件名

在调用#include时，了解您希望如何编写页眉，可以帮助您决定将它们放在更舒适的位置。

就我而言，我并不真正喜欢标题/源分隔。有些头不打算由我的API公开，所以我要么把所有的源都放在一个文件夹中，要么我更喜欢公共/私有分离。