C++ 为应用程序级代码分隔“include”和“src”文件夹？

Separate "include" and "src" folders for application-level code?

提问by StackedCrooked

This questions concerns mostly Unix/Linux style C++ development. I see that many C++ librariesstore their header files in a "include" folder and source files in an "src" folder. For the sake of conformance I adopted this in my own code. But it is not clear to me whether this should be done for applicationcode as well. I've seen a few cases where a flat directory structure is used for that. What would be the recommended approach?

这个问题主要涉及 Unix/Linux 风格的 C++ 开发。我看到许多 C++库将它们的头文件存储在“include”文件夹中，并将源文件存储在“src”文件夹中。为了一致性，我在自己的代码中采用了这一点。但我不清楚是否也应该对应用程序代码执行此操作。我见过一些使用平面目录结构的情况。推荐的方法是什么？

采纳答案by Patrick

I also separate them, but not strictly on the extension, but on the access of the file.

我也将它们分开，但不是严格按照扩展名，而是按照文件的访问权限。

Suppose you have a module that manages customer information and uses 2 classes to do this: Customer, CustomerValidityChecker. Also suppose that other parts in your application only need to know about the Customer class, and that the CustomerValidityChecker is only used by the Customer class to perform some checking. Based on these assumptions I store the files like this:

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

Public folder (or include folder):

公共文件夹（或包含文件夹）：

• customer.h

• 客户.h

Private folder (or source folder):

私人文件夹（或源文件夹）：

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

• 客户.cpp
• customervaliditychecker.h
• customervaliditychecker.cpp

That way, it becomes immediately clear for callers of your module which parts are accessible (public) and which parts aren't.

这样，模块的调用者就可以立即清楚哪些部分是可访问的（公共的），哪些部分不可访问。

回答by Mike DeSimone

We have a build system that auto-generates our makefiles. One thing it does is recursively descend any subdirectories and build them as libraries, linking them together with the main directory's objects to make the application. (In practice, these "subdirectories" are usually symbolic links.) Libraries are static unless the directory name ends in ".so". One thing that's nice about this is that a full build of our system, which has many executables, doesn't have to repeatedly compile the common libraries.

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

However, as a result of this, there's no separation of headers and sources. And it has never been a problem. Honestly, I think it's better this way because headers and source files have commonality of location, and you can grab a directory and know you got everything you need to use it. It also works great with Subversion's "externals" feature, and similar features in other VCSs.

但是，因此，标题和来源没有分离。它从来都不是问题。老实说，我认为这种方式更好，因为头文件和源文件具有共同的位置，您可以获取一个目录并知道您拥有使用它所需的一切。它也适用于 Subversion 的“外部”功能以及其他 VCS 中的类似功能。

One last place where an include/src separation fails is if you use any code generators, such as flex, bison, or gengetopts. Figuring out where these tools should put their outputs so they get built is tricky if you've spread things out.

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

回答by bshields

It makes sense to separate them for shared libraries because they may be distributed in a compiled form without the source. I've seen projects that separate out "public" headers (headers that may be accessed from code outside your project or library) while leaving "private" headers and source files in the same directory. I think it's good to use a consistent approach whether you're writing shared library or application level code because you never know when you may want to turn something that you've written at the application level into a lower level library that is shared by multiple projects.

将它们分开用于共享库是有意义的，因为它们可能以没有源代码的编译形式分发。我见过一些项目将“公共”头文件（可以从项目或库之外的代码访问的头文件）分开，同时将“私有”头文件和源文件保留在同一目录中。我认为无论您是在编写共享库还是应用程序级别的代码，都最好使用一致的方法，因为您永远不知道何时可能想要将您在应用程序级别编写的内容转换为由多个共享的较低级别的库项目。

回答by Jerry Coffin

A lot depends on the size of project involved. Up to a few dozen files or so, keeping them in one directory tends to be more convenient. For a bigger application that includes hundreds or thousands of files, you start to look for ways to separate them (though in the projects I've worked on, it was done more on functional lines than src/include). In between those, it's probably open to question.

在很大程度上取决于所涉及项目的规模。多达几十个文件左右，将它们保存在一个目录中往往更方便。对于包含成百上千个文件的更大的应用程序，您开始寻找将它们分开的方法（尽管在我参与的项目中，它在功能行上比 src/include 做得更多）。在这两者之间，它可能是值得商榷的。

回答by Michael Mrozek

I don't do this; there seems little advantage in it. Since headers tend to have a different extension from source files, you can have your editor show them separately if you really feel the need -- Visual Studio does this by default, but I disable it since I prefer seeing them together

我不这样做；它似乎没有什么优势。由于标头往往与源文件具有不同的扩展名，如果您真的觉得需要，可以让编辑器单独显示它们——Visual Studio 默认执行此操作，但我禁用它，因为我更喜欢将它们放在一起

回答by Kungi

I almost always create include and src folders to split up my source code. I think it makes the folder less cluttered and files are easier to find in my IDE. But I think this is just a matter of taste.

我几乎总是创建 include 和 src 文件夹来拆分我的源代码。我认为它使文件夹不那么混乱，并且在我的 IDE 中更容易找到文件。但我认为这只是品味问题。

Either method is valid. It depends on the coding style you want to follow how you do this.

任何一种方法都是有效的。这取决于您要遵循的编码风格。

回答by Amardeep AC9MF

There is no clear advantage to either in my view. I finally decided to keep program and header files together because my editor (Visual SlickEdit) happens to provide additional referential features when they are not separated.

在我看来，两者都没有明显的优势。我最终决定将程序和头文件放在一起，因为我的编辑器 (Visual SlickEdit) 在它们没有分开时恰好提供了额外的参考功能。

回答by Thomas Matthews

I place include (header) and source files in the same directory (folder). I create different folders for different themes. I get frustrated when trying to find header files (while debugging and also for researching). In some shops, there are only two folders: source and includes. These directories tend to grow exponentially. Reusing code becomes a nightmare at best.

我将包含（头文件）和源文件放在同一目录（文件夹）中。我为不同的主题创建不同的文件夹。我在尝试查找头文件时感到沮丧（在调试和研究时）。在一些商店中，只有两个文件夹：源和包含。这些目录往往呈指数增长。重用代码充其量只是一场噩梦。

IMHO, I believe organizing by theme is better. Each theme folder should build into at least one library. Different projects can easily include the themes by searching or including the folders. The projects only need to include the libraries. Smart build engines can list the theme folders as dependencies. This speeds up the build process.

恕我直言，我相信按主题组织会更好。每个主题文件夹都应构建到至少一个库中。不同的项目可以通过搜索或包含文件夹轻松包含主题。项目只需要包含库。智能构建引擎可以将主题文件夹列为依赖项。这加快了构建过程。

The theme organization also adds a bit of safety to the project. Accidental damage to files (such as removing the wrong ones or replacing with different versions) is reduced since files are located in different directories. Deletion of files in the "Person" folder will not affect files in the "Shape" folder.

主题组织也为项目增加了一些安全性。由于文件位于不同的目录中，因此减少了对文件的意外损坏（例如删除错误的文件或替换为不同版本）。删除“Person”文件夹中的文件不会影响“Shape”文件夹中的文件。

This is just my opinion, Your Mileage May Vary.

这只是我的意见，您的里程可能会有所不同。

回答by Engineer

Bottom Line: sources and headers that are still changing go in /src. Code that has crystallised should go in /lib& /include(actually you could keep all .libs and their .hs in /lib).

底线：仍在更改的源和标题进入/src。已经结晶的代码应该进入/lib& /include（实际上你可以将所有.libs 和它们的.hs保留在 中/lib）。

• Keep own sources and headers together, provided they are (a) specific to this project or (b) have not yet been factored out as a shared library.
• Once certain sources in the main project have been factored out as a (relatively stable) library, place the .aor .libinto /lib, and its public interface header into /include.
• All third party libraries and their public interface headers also go into /lib& /include.

• 将自己的源代码和头文件放在一起，前提是它们 (a) 特定于此项目或 (b) 尚未被分解为共享库。
• 一旦主项目中的某些源被分解为（相对稳定的）库，将.a或.lib放入/lib，并将其公共接口头放入/include.
• 所有第三方库及其公共接口标头也进入/lib& /include。

As others note, it is often more compatible for tools / IDEs to access .h/.cfrom one folder. But from an organisational view it can be useful to separate changing local code from stable lib code.

正如其他人所指出的，工具/IDE 通常更兼容从一个文件夹访问.h/ .c。但是从组织的角度来看，将不断变化的本地代码与稳定的 lib 代码分开是很有用的。

回答by Johan Moreau

We have a build system which use this rule. This build system is sconspiracya set of scripts to configure SCons and dedicated to the C++ world. You can see an example which use this tools : fw4spl

我们有一个使用此规则的构建系统。此编译系统sconspiracy一套脚本来配置SCons的，并且专用于C ++的世界。你可以看到一个使用这个工具的例子：fw4spl