33

我知道在 C/C++ 项目中将头文件放在一个目录中是很常见的，例如将头文件放在include一个单独的目录中，例如src. 我一直在玩弄不同的项目结构，想知道这是否有任何客观原因，还是只是惯例？

4

5 回答 5

35

约定是原因之一——大多数时候，通过有效的抽象，您只关心接口并且希望只看标题就可以轻松。

但这不是唯一的原因。如果您的项目是按模块组织的，您很可能必须在不同的模块中包含一些标头，并且您希望您的包含目录中的其他“噪音”文件被清除。

此外，如果您计划重新分发您的模块，您可能希望隐藏实现细节。因此，您只提供标头和二进制文件 - 从一个文件夹中分发标头，其中没有其他内容更简单。

还有一个我实际上更喜欢的替代方案——公共头文件放在一个单独的文件夹中（这些包含最小的接口——没有任何实现细节可见），私有头文件和实现文件是分开的（可能但不一定在单独的文件夹中） .

于 2012-12-20T07:41:07.723 回答
17

我更喜欢将它们放在同一个目录中。原因：

接口规范文件和实现该接口的源文件属于项目的同一部分。说你有subsystemx。那么，如果你把subsystemx文件放在subsystemx目录下，subsustemx是自包含的。

如果有很多包含文件，你当然可以做subsystemx/includeand subsystemx/source，但是我认为如果你把 in 的定义class Foo放在一起foo.hpp，foo.cpp你当然想在一个目录列表。查找所有相关文件foo

ls foo*

查找所有实现文件：

ls *.cpp

查找所有声明文件：

ls *.hpp

简单干净。

于 2016-06-24T14:08:43.457 回答
6

它使您的文件夹结构更清洁。头文件和源文件明显不同，用于不同的事物，因此将它们分开是有意义的。从这个角度来看，问题基本上与“为什么源文件和文档放在不同的文件夹中”相同？计算机对于您在文件夹中放入什么和不放入什么是高度不可知的，由于我们人类解析、存储和调用信息的方式，文件夹在大多数情况下只是一个方便的抽象。

还有一个事实是，即使在您构建后头文件仍然有用，即如果您正在构建一个库并且有人想要使用该库，他们将需要头文件 - 而不是源文件 - 所以它使将这些头文件捆绑在一起——将内容抓取bin进来include，而不必进行筛选src——要容易得多。

于 2012-12-20T07:40:57.820 回答
3

除了（有争议的？）对保持事物有序、在其他项目中有用等有用之外，还有一个非常中立和客观的优势：编译时间。

特别是，在一个包含一大堆文件的大型项目中，取决于头文件的搜索路径（使用#include "headername.h"而不是.c/.cpp 文件#include "../../gfx/misc/something/headername.h"，并且编译器传递了正确的参数以便能够吞下它），您会大大减少数量需要由编译器扫描以搜索正确标题的条目。由于大多数编译器为每个编译的文件单独启动，它们需要读取包含路径上的文件列表并为每个编译的文件寻找正确的头文件。如果包含路径上有一堆 .c、.o 和其他不相关的文件，则在其中查找包含所需的时间相应地更长。

于 2012-12-20T08:24:36.887 回答
0

简而言之，有几个原因：

  • 可维护的代码。
  • 代码设计良好且整洁。
  • 更快的编译时间（有时，对于完成的小改动）。
  • 更容易分离文档等的接口。
  • 可以避免编译时的循环依赖。
  • 易于审查。

看看文章用 C 和 C++ 组织代码文件，它很好地解释了它。

于 2016-06-08T11:14:12.700 回答