应用程序级代码分开"include"和"src"文件夹?

Sta*_*ked 51 c++ project-management

这个问题主要涉及Unix/Linux风格的C++开发.我看到许多C++ 将其头文件存储在"include"文件夹中,源文件存储在"src"文件夹中.为了一致性,我在自己的代码中采用了这个.但是我不清楚是否应该对应用程序代码进行此操作.我已经看过一些使用平面目录结构的情况.推荐的方法是什么?

Pat*_*ick 47

我也将它们分开,但不是严格地在扩展名上,而是在文件的访问权上.

假设您有一个管理客户信息的模块,并使用2个类来执行此操作:Customer,CustomerValidityChecker.还假设应用程序中的其他部分只需要了解Customer类,并且CustomerValidityChecker仅由Customer类用于执行某些检查.根据这些假设,我存储这样的文件:

公用文件夹(或包含文件夹):

  • customer.h

私人文件夹(或源文件夹):

  • 为customer.cpp
  • customervaliditychecker.h
  • customervaliditychecker.cpp

这样,模块的调用者就可以立即清楚哪些部分是可访问的(公共),哪些部分不可访问.


Mik*_*one 8

我们有一个自动生成makefile的构建系统.它做的一件事是递归下降所有子目录并将它们构建为库,将它们与主目录的对象链接在一起以构成应用程序.(实际上,这些"子目录"通常是符号链接.)除非目录名以".so"结尾,否则库是静态的.对此有一点好处是我们的系统的完整版本具有许多可执行文件,不必重复编译公共库.

但是,由于这个原因,标题和源代码没有分离.它从来都不是问题.老实说,我觉得这样更好,因为标题和源文件具有共同的位置,你可以获取一个目录,并知道你拥有了使用它所需的一切.它也适用于Subversion的"外部"功能,以及其他VCS中的类似功能.

include/src分离失败的最后一个地方是使用任何代码生成器,例如flex,bison或gengetopts.如果你把事情分散开来,弄清楚这些工具应该把它们的输出放在哪里以便它们构建起来是很棘手的.

  • 老实说,我也喜欢将头文件和源文件放在一起。也在一个 Visual Studio 过滤器中,以便头文件和源文件放在一起。 (4认同)

bsh*_*lds 7

将它们分离为共享库是有意义的,因为它们可以在没有源的情况下以编译形式分发.我已经看到了将"公共"标题(可以从项目或库外部的代码访问的标题)分开的项目,同时将"私有"标题和源文件保留在同一目录中.我认为使用一致的方法是好的,无论你是编写共享库还是应用程序级代码,因为你永远不知道什么时候你可能想把你在应用程序级别编写的东西转换成由多个共享的低级库项目.


Jer*_*fin 5

在很大程度上取决于所涉及项目的规模。多达几十个文件左右,将它们保存在一个目录中往往更加方便。对于包含数百或数千个文件的更大的应用程序,您开始寻找分离它们的方法(尽管在我从事的项目中,它在功能上比在src / include上做得更多)。在这两者之间,可能存在疑问。