我知道在C / C ++项目中，将头文件放在include等目录中并在src这样的单独目录中实现是很常见的。我一直在玩弄不同的项目结构，我想知道是否有任何客观原因，或仅仅是惯例？
答案 0 :(得分：28)
约定是其中一个原因 - 大部分时间，通过有效的抽象，你只关心界面，并希望只是看看标题。
这不是唯一的原因。如果您的项目是按模块组织的，那么您很可能必须在不同的模块中包含一些标题，并且您希望清除包含目录中的其他“噪声”文件。
此外，如果您计划重新分发模块，则可能需要隐藏实现细节。因此，您只提供标题和二进制文件 - 并且从单个文件夹中分发标题，其中没有其他内容更简单。
还有替代我实际上更喜欢 - 公共标题放在一个单独的文件夹中（这些包含最小的接口 - 没有任何实现细节可见），私有标头和实现文件是分开的（可能，但不一定，在单独的文件夹中）。
答案 1 :(得分：7)
我更喜欢将它们放入相同的目录中。原因是：
接口规范文件和实现该接口的源文件属于项目的同一部分。假设你有subsystemx。然后，如果您将subsystemx个文件放在subsystemx目录中，则subsustemx是自包含的。
如果有很多包含文件，请确保您可以执行subsystemx/include和subsystemx/source，但我认为如果您将class Foo的定义放在foo.hpp中， foo.cpp你当然希望在目录列表中同时看到它们（或者至少有可能这样做）。查找与foo
ls foo*
查找所有实施文件：
ls *.cpp
查找所有声明文件：
ls *.hpp
简单干净。
答案 2 :(得分：6)
它可以保持文件夹结构更清晰。标题和源文件明显不同，并且用于不同的事情，因此将它们分开是有意义的。从这个角度来看，这个问题与“为什么源文件和文档进入不同的文件夹”基本相同？计算机对于你放在文件夹中的内容以及你不使用的内容是高度不可知的，文件夹在大多数情况下只是一个方便的抽象，因为我们人类解析，存储和调用信息的方式。
还有一个事实是头文件仍然有用即使你已经构建，即如果你正在构建一个库而有人想要使用该库，他们将需要头文件 - - 不是源文件 - 因此它会捆绑这些头文件 - 抓取bin中的内容和include中的内容而不必筛选src - 更容易
答案 3 :(得分：2)
除了（可论证的？）保持秩序有用，在其他项目等方面有用之外，还有一个非常中立和客观的优势：编译时间。
特别是在一个包含大量文件的大型项目中，取决于标题的搜索路径（.c / .cpp文件使用#include "headername.h"而不是#include "../../gfx/misc/something/headername.h"并且编译器通过了权限可以吞下的参数）你大大减少了编译器在搜索正确的标题时需要扫描的条目数。由于大多数编译器会针对编译的每个文件单独启动，因此需要读取包含路径上的文件列表并为每个编译文件寻找正确的标头。如果包含路径上有一堆.c，.o和其他无关文件，那么在其中找到包含的内容会成比例地延长。
答案 4 :(得分：0)
总之，有几个原因：
查看文章Organizing Code Files in C and C++ ，它解释得很清楚。