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).
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 .a or .lib into /lib, and its public interface header into /include.
All third party libraries and their public interface headers also go into /lib & /include.
As others note, it is often more compatible for tools / IDEs to access .h/.c from one folder. But from an organisational view it can be useful to separate changing local code from stable lib code.
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.
我们有一个使用此规则的构建系统。此构建系统是 sconspiracy 一组用于配置 SCons 的脚本，专用于 C++ 世界。您可以查看使用此工具的示例：fw4spl
We have a build system which use this rule. This build system is sconspiracy a set of scripts to configure SCons and dedicated to the C++ world. You can see an example which use this tools : fw4spl
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:
Public folder (or include folder):
customer.h
Private folder (or source folder):
customer.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.
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.
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.
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.
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.
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.
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 Studio 默认情况下会这样做，但我禁用它，因为我更喜欢将它们放在一起
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
我几乎总是创建 include 和 src 文件夹来分割我的源代码。我认为这使得文件夹不再那么混乱，并且在我的 IDE 中更容易找到文件。但我认为这只是一个品味问题。
任何一种方法都是有效的。这取决于您想要遵循的编码风格。
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.
Either method is valid. It depends on the coding style you want to follow how you do this.
发布评论
评论（10）
底线：仍在更改的源代码和标头位于
/src中。已经具体化的代码应该放在/lib& 中。/include（实际上，您可以将所有.lib及其.h保留在/lib中）。.a或.lib放入/lib，并将其公共接口标头放入/include中。/lib& <代码>/包括。正如其他人所指出的，工具/IDE 从一个文件夹访问
.h/.c通常更兼容。但从组织的角度来看，将不断变化的本地代码与稳定的库代码分开可能很有用。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)..aor.libinto/lib, and its public interface header into/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.我将包含（标头）和源文件放在同一目录（文件夹）中。我为不同的主题创建不同的文件夹。当我尝试查找头文件时（在调试和研究时），我感到很沮丧。在某些商店中，只有两个文件夹：源文件和包含文件。这些目录往往呈指数级增长。重用代码充其量只是一场噩梦。
恕我直言，我相信按主题组织更好。每个主题文件夹应至少构建一个库。不同的项目可以通过搜索或包含文件夹轻松包含主题。项目只需要包含库。智能构建引擎可以将主题文件夹列为依赖项。这加快了构建过程。
主题组织也给项目增添了一点安全感。由于文件位于不同的目录中，因此减少了文件的意外损坏（例如删除错误的文件或替换为不同的版本）。删除“Person”文件夹中的文件不会影响“Shape”文件夹中的文件。
这只是我的意见，您的里程可能会有所不同。
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.
This is just my opinion, Your Mileage May Vary.
我们有一个使用此规则的构建系统。此构建系统是 sconspiracy 一组用于配置 SCons 的脚本，专用于 C++ 世界。您可以查看使用此工具的示例：fw4spl
We have a build system which use this rule. This build system is sconspiracy a set of scripts to configure SCons and dedicated to the C++ world. You can see an example which use this tools : fw4spl
我也将它们分开，但不是严格按照扩展名，而是按照文件的访问权限。
假设您有一个管理客户信息的模块，并使用 2 个类来执行此操作：Customer、CustomerValidityChecker。
还假设应用程序中的其他部分只需要了解 Customer 类，并且 CustomerValidityChecker 仅由 Customer 类使用来执行某些检查。
基于这些假设，我存储如下文件：
公共文件夹（或包含文件夹）：
私人文件夹（或源文件夹）：
这样，您的调用者就会立即清楚模块的哪些部分可以访问（公共），哪些部分不可访问。
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:
Public folder (or include folder):
Private folder (or source folder):
That way, it becomes immediately clear for callers of your module which parts are accessible (public) and which parts aren't.
我们有一个自动生成 makefile 的构建系统。它所做的一件事是递归地下降任何子目录并将它们构建为库，将它们与主目录的对象链接在一起以创建应用程序。 （实际上，这些“子目录”通常是符号链接。）除非目录名称以“.so”结尾，否则库是静态的。这样做的好处之一是，我们的系统的完整构建（包含许多可执行文件）不必重复编译公共库。
然而，因此，标头和源没有分离。这从来都不是问题。老实说，我认为这种方式更好，因为标头和源文件具有相同的位置，并且您可以获取一个目录并知道您已获得使用它所需的一切。它还可以很好地与 Subversion 的“外部”功能以及其他 VCS 中的类似功能配合使用。
include/src 分离失败的最后一个地方是如果您使用任何代码生成器，例如 flex、bison 或 gengetopts。如果您将东西分散开来，那么弄清楚这些工具应该将其输出放在哪里以便构建它们是很棘手的。
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.
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.
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.
将它们分离为共享库是有意义的，因为它们可能以编译形式分发而无需源代码。我见过一些项目分离出“公共”标头（可以从项目或库外部的代码访问的标头），同时将“私有”标头和源文件保留在同一目录中。我认为无论您是编写共享库还是应用程序级代码，都最好使用一致的方法，因为您永远不知道什么时候可能想要将在应用程序级编写的内容转换为由多个共享的较低级库项目。
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.
很大程度上取决于所涉及项目的规模。最多有几十个文件左右，将它们保存在一个目录中往往会更方便。对于包含数百或数千个文件的较大应用程序，您开始寻找分离它们的方法（尽管在我从事过的项目中，它在功能行上完成的工作比 src/include 更多）。在这两者之间，它可能值得商榷。
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.
在我看来，两者都没有明显的优势。我最终决定将程序和头文件放在一起，因为我的编辑器（Visual SlickEdit）在它们不分开时恰好提供了额外的参考功能。
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 Studio 默认情况下会这样做，但我禁用它，因为我更喜欢将它们放在一起
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
我几乎总是创建 include 和 src 文件夹来分割我的源代码。我认为这使得文件夹不再那么混乱，并且在我的 IDE 中更容易找到文件。但我认为这只是一个品味问题。
任何一种方法都是有效的。这取决于您想要遵循的编码风格。
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.
Either method is valid. It depends on the coding style you want to follow how you do this.