如何在C++中逻辑组织源代码文件

12

我的源文件窗格(指项目中的文件数量)正在快速增长,每当需要访问特定的源文件时,快速定位变得有些麻烦。我在使用 Embarcadero 的 C++Builder,但在其他 C++ IDE 中也遇到了这个问题。

在 Java 中,我经常使用包来创建源代码的逻辑分区,尤其是在处理单个项目中大量源文件时。虽然这当然不是 Java 包的唯一用途,但在这方面它们非常方便。

是否有人有任何想法,可以让我在 C++ 中实现类似的功能?我应该将我的源代码分离到物理文件夹中吗?C++Builder 是否提供某种虚拟文件夹/分组功能,我只是没有发现?感谢您的任何想法。


1
我通常通过类浏览器导航,而不是依赖源文件组织。 - Captain Obvlious
3
整理成文件夹。如果它是一个大模块,我建议将其制作成一个项目。 - someone_ smiley
1
哎呀,我可能不是适合提问的人。我对组织非常挑剔,我的IDE很少打开超过三个源文件,我的项目始终设置有一个src/文件夹,如果情况开始变得混乱(这种情况很少发生,因为我不支持大二进制文件)。此外还有一个项目include/文件夹,用于跨功能包含。 - WhozCraig
Visual Assist X 可以帮助在 Visual Studio 中高效地定位源文件。与 Xcode 或甚至 KDevelop 相比,VS 在这方面确实有所欠缺。 - Wilbert
我与Whole Tomato没有任何关联。最近,我开始在Windows上工作,真的遭受了Visual Studio中的缺陷之苦,而我提到的工具帮了大忙。是的,我同意这是标准功能,实际上应该内置在VS中。但它没有。 - Wilbert
3个回答

13

一般来说,我建议不要仅仅使用IDE或语言语法来组织你的源代码。首先,这会将你与环境绑定在一起:在IDE中组织得很好,在文件中却不整洁,那么当你想要使用不同的环境时就会出现问题...

因此,我通常同时使用三种方式来组织我的源代码:我将我的源代码分成功能模块,即相关类。每个模块都有自己的命名空间、物理文件夹和IDE文件夹。(在我的情况下,使用CMakesource_group()生成必要的IDE工程文件——我个人倾向于使用命令行、Vim和“make”。)

因此,无论是从IDE、命令行还是编译器日志来查看项目,foo/some_class.hpp都是foo/some_class.cpp都是foo::some_class,最大限度地减少了混乱。

实际上,我目前更喜欢的设置是进一步将每个模块目录细分为<project>/<module>/<class>.hpp<project>/<module>/src/<class>.hpp,具体取决于类是否在其自己的模块之外使用,<project>/<module>/src/<class>.cpp<project>/<module>/test/<class>_tu.cpp。命名空间当然是<project>::<module>::<class>

project
|-- foo
|   |-- some_class.hpp
|   |-- src
|   |   |-- internal_class.hpp
|   |   |-- internal_class.cpp
|   |   `-- some_class.cpp
|   `-- test
|       |-- internal_class_tu.cpp
|       `-- some_class_tu.cpp
|-- bar
|   |-- ...
在这里的想法是每个模块(foo)的“外部”接口都由该子文件夹中的头文件进行文档化,而实现细节和测试则“隐藏”在相应的子文件夹中。但最终结果很大程度上取决于您的喜好、与您合作开发者的喜好以及项目的范围。

这似乎是全面最佳的解决方案。特别是如果我的项目将来迁移到不同的IDE上,而且它将在所有方面为我提供保障。感谢你有帮助的回答。 - arkon
@b1nary.atr0phy:也许你会对JAWS感兴趣(这是我在此期间设置的东西)... - DevSolar

13

这就是我的风格:

PROJECT_NAME
|-- build // This is DVCS ignored but has all the built intermediates and final binaries
|   |-- release // These are the different build profiles
|   |-- debug
|   |-- profile
|   `-- coverage
|-- bin // For binary source code
|   `-- hello_world
|       |-- doc
|       |-- inc
|       |-- src
|       |-- tests
|       `-- build_script  // Builds binary into the build folder
|-- include // Public headers for the library
|   `-- these
|       `-- folders
|           `-- represent
|               `-- namespaces
|                   `-- my_awesome_class.hpp
|-- lib // library source code
|   |-- these
|   |   `-- folders
|   |       `-- represent
|   |           `-- namespaces
|   |               |-- inc // Private headers
|   |               |   `-- my_private_class.hpp // internal class
|   |               |-- src // Source code for this namespace
|   |               |   |-- posix
|   |               |   |   `-- my_awesome_class.cpp // posix specific source code
|   |               |   |-- nt
|   |               |   |   `-- my_awesome_class.cpp // nt specific source code
|   |               |   |-- my_private_class.cpp // non-visibile class
|   |               |   `-- my_awesome_class.cpp // cross platform source code
|   |               |-- tests // Unit tests
|   |               |   `-- my_awesome_class.cpp // builds a test executable for the library
|   |               `-- doc // Documentation for this namespace
|   |                   `-- namespace.dox
|   `-- build_script  // Builds binary into the build folder
|-- doc // Documentation files
|   |-- main_page.dox
|   `-- namespace.dox
`-- build_script  // Builds the source code into the build folder

这代表了these::folders::represent::namespaces::MyAwesomeClass类,它具有posixNT特定的源代码(以及通用源代码),还有一个私有的these::folders::represent::namespaces::MyPrivateClass在库内部使用,头文件不是公共的,类符号的visibility被隐藏。
这样做非常有效,并且提供了方便的文件定位。

源代码外构建也非常整洁。我建议删除 build 目录并从 ../build_whatever_mode 进行构建。 - Offirmo

0

我制作项目以便轻松访问所有文件。这是最简单的组织方式,加上清晰的类/文件名称。


5
实际上,我在第一句话中就表明了我所处理的是一个项目。我的问题是如何组织该项目中的源文件。当涉及到相对较多的类时,仅仅给它们命名是不够清晰的。 - arkon

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接