如何布局 C++ 代码：Visual Studio 2010 中的命名空间和类似文件名

Question

这是一个比较笼统的问题，因为我在网上找到的关于如何最好地组织源代码的信息相对较少。

我目前布置代码的方式是在 VS 中编译一个 lib 项目，然后在此之上创建两个控制台应用程序项目，一个用于单元测试，一个用于执行 lib 中的代码。

在主项目中，我有一个名为 src 的文件夹，其中包含我的 src 代码。然后将这个源代码组织到不同的文件夹中，每个文件夹都包含 .h 和 .cpp 文件。文件名与类名匹配。文件夹匹配命名空间，因此每个文件夹都在自己的命名空间中。

我认为这是一种非常明智的方法，直到我发现如果两个 .cpp 文件具有相同的名称（尽管在不同的文件夹和命名空间中），Visual Studio 2010 会在这种方法下出现问题，因为所有 .obj 文件都放在相同的临时目录（Debug 或 Release）。

这让我想知道，维护大量命名空间和子命名空间的目的肯定是让您拥有同名的类和文件。一些 google-ing 提出了单独选择冲突文件并将 .obj 文件放置到不同位置的解决方案，但有些暗示性能更差，这似乎有点奇怪。

所以我只是想知道，这不是一个明智的布局吗？还是人们通常将每个文件夹编译成一个静态库然后链接它们？或者你只是维护不同的文件名？然后，您是否继续将文件名与类名匹配？因为如果你这样做了，你也不需要子命名空间，因为整个项目可能只是在一个命名空间中......

我想知道，我在思考……不确定这个问题是否足够具体。我想我的直接问题（假设布局有点明智）是如何解决冲突的 obj 文件？我只是想在维护类名的同时重命名文件。但我不太喜欢这种解决方案。

谢谢（抱歉问题太长了）

附：源码文件夹要兼容linux下的gcc

Answer 1

IDE 通常可以让您按逻辑排列文件。 （Visual Studio 和 XCode 至少都允许您创建分层组来排列源文件，这与文件在磁盘上的位置不对应。

因为大多数 IDE 将所有源文件编译到一个公共中间文件夹以进行链接步骤，所以任何同名的源文件都可能产生冲突，其中要编译的第二个文件会覆盖前一次编译的 .o 或 .obj。

因此，我倾向于采用务实的方法：单个目标（静态库、dylib、exe）的所有文件都包含在一个文件夹中。特定于平台或特定于功能的文件位于特定的子文件夹中，因此只需一次添加（或删除）一个文件文件夹，就可以轻松地为不同的平台/配置重建项目。这确实（事后看来）似乎是有效使用文件系统的最有用的方式。

与其创建深层次的子结构，每次单个库变得过于繁琐时，我都拆分出一个新的静态库。

这很好地映射到基本项目结构 IDE，如 Visual Studio 和 XCode，往往暗示其向导的最佳实践：一个项目文件夹，包含多个目标文件夹，每个目标文件夹包含其源文件。

Answer 2

我设置

    Properties -> C/C++ -> Output Files -> Output File Name

到

    V:\%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj

假设项目位于驱动器V 上，则 OBJ 文件最终位于源旁边（尚不知道是否有宏）。