C++中的SRC/文件夹结构?

我一直喜欢每个文件夹的名称空间。主要是因为当我必须维护其他人的代码时,名称空间帮助我找到类最初定义的位置。

不过,命名良好的头文件也有助于解决这个问题。我也不会建议超过2-3个命名空间,因为它会变得令人讨厌。你会发现自己使用“使用命名空间BLAH”,我经常发现它是C++代码的红旗。而且,在头文件中使用“using namespace”不能避免出现一些严重的问题。

在C++中完全是可选的。

你可能想看看约翰·拉科斯 Large-Scale C++ Software Design . 基本上,您可以这样做,但是您的包(如在Java中)应该有一个非循环依赖关系图。此外,对于每个包来说,记录哪些头是导出的,哪些不是,也许像这样:

src/
 |- package1/
     |- exported_symbols_1.hh
     |- exported_symbols_2.hh
     |- src/
         |- impl_1.hh
         |- impl_1.cc
 |- package2/
     |- sub_package_2_1/
         |-  exported.hh
         |-  src/
                 ...
      |- src/
            ...

每个包只允许包含另一个包的顶级头,而不允许包含 src/ 目录。

而且,当你想使用 Autotools 在一个大型项目中,如果打算分发头文件,那么可以谨慎地调用顶级目录 src公司/ 但是 PACKAGE_TARNAME 关于那个项目。这使得在 自动工具 更容易的。

(当然,实际的文件名并不像上面所示的那样愚蠢。)

没有理由不将源代码分成不同的目录;如果有许多文件和清晰的逻辑分组,这是有意义的。

不过,在大型项目中,没有必要为每个小类创建一个不同的文件,这样会减慢编译速度(因为实现文件常常必须包含许多相同的头,只需编译它们的几十行)。

除了使用名称空间来反映代码中的逻辑分区之外,将代码细分为其他名称空间的确切阈值往往还受到一些其他因素的驱动,例如:

• 建议使用更多名称空间的因素
  • 非常不稳定的代码(经常编辑,经常附加/更改标识符的使用,经常是简短和/或常用词)
  • 更多的开发人员
• 减少名称空间需求的因素
  • 中心机构的紧密配合
  • 计划正式发布,并彻底检查冲突

名称空间还可以用作一种方式,允许在替代实现(例如,不同版本的协议、线程安全与不安全的支持函数、特定于操作系统的实现)之间轻松切换,因此有时满足此类需求需要需要使用不同的名称空间。

通过不直观和/或深度嵌套的名称空间来访问所需的变量肯定会很痛苦,如果您可能无论如何都需要使用多个定义相同标识符的名称空间,但可以适应更频繁地同时使用一个或另一个名称空间的模式代码,则“使用名称空间”的效率会更低。

因此,在决定是否将每个文件夹的代码(或其他逻辑上不同的组)放入不同的名称空间时,可能需要考虑这些因素。

没有理由不去帮助人们阅读你的代码。需要注意的一些事情:

1. 不要 结束 -嵌套文件夹,这可能会让代码的读者感到困惑。
2. 在代码的组织中保持一致,例如不要 任何 在controllers子目录中查看代码,反之亦然。
3. 保持布局干净。

您可以随意排列文件;只需调整生成工具的包含路径和源路径即可。

给每个目录赋予它自己的名称空间是一个过火的想法,而且可能是一个坏主意,因为这会导致代码混乱。我建议每个项目最多使用一个名称空间,甚至每个公司只使用一个名称空间(因为可能在您的公司内,如果需要解决名称冲突,您可以重命名内容)。名称空间的主要目的是处理在两个不同组织控制下的两个代码库都使用同一名称,而您作为第三方希望在同一项目中同时使用它们,但无法修改任何一个代码库的情况。

src/是c/c++程序员将源代码放在项目根目录中的常见位置。 例如:

doc/    <- documentation
libs/   <- additional libraries
po/     <- gettext translations
src/    <- sources

如果有很多源文件,通常在src/下面创建子目录,但是如何组织这个子结构没有限制。

请记住,目录结构在c++中是完全可选的。c++命名空间和目录结构之间没有连接。