我从Java / AS3-land进入C ++,我习惯了我的类的包兼文件夹结构。我喜欢它。
我理解c ++中命名空间的基础知识,我很高兴将它留在基础知识中。但是,随着我的项目变得越来越复杂,我想保持我的文件夹结构有条不紊地保持在我的头脑中。即类似于Java / AS3的东西。
1)是否有任何理由不具有如下文件夹结构:
src/
model/
view/
controller/
可能有子文件夹? (这只是一个MVC示例,根据项目的需要,文件夹结构可以是任何东西。)如果src /文件夹中包含大量的头文件和源文件,这似乎是不守规矩的。
2)如果1)的答案可能是“继续做你想做的事”,那么为每个文件夹创建命名空间是不明智/不必要的,类似于Java / AS3为每个文件夹创建一个包的方式?我的理解是名称空间通常不像这样使用,嵌套深度和文件夹相关。
答案 0 :(得分:7)
您可能想看看John Lakos 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/
...
每个包只允许#include另一个包的顶级标题,而不允许包含src/
目录中的标题。
此外,如果您想在大型项目中使用Autotools
并打算分发标题,那么调用顶级目录而不是src/
而不是{{1}可能是明智的。那个项目。这样可以更轻松地在PACKAGE_TARNAME
的帮助下安装标题。
(当然,实际的文件名看起来并不像上面所说的那么愚蠢。)
答案 1 :(得分:7)
我一直很喜欢每个文件夹的命名空间。主要是因为当我必须维护其他人的代码时,命名空间可以帮助我找到最初定义类的位置。
良好命名的头文件也可以帮助解决这个问题。我也不会建议超过2-3个命名空间,因为它只是变得令人讨厌。你会发现自己使用“using namespace blah;”我总是发现很多C ++代码的红旗。并且您不能在头文件中使用“using namespace”而不会发生严重问题。
尽管在C ++中,它完全是可选的。
答案 2 :(得分:1)
没有理由不将源代码划分到不同的目录中;如果有很多文件和清晰的逻辑分组,这是有道理的。
没有必要为每个小类创建一个不同的文件 - 在大型项目中,这往往会减慢编译速度(因为实现文件通常必须包含许多相同的标题才能编译它们的几十行)
除了使用命名空间来反映代码中的逻辑分区之外,代码被细分为更多命名空间的确切阈值往往是由其他一些力量驱动的,例如:
命名空间也可以用作允许在替代实现之间轻松切换的方式(例如,协议的不同版本,线程安全支持功能与不安全支持功能,特定于操作系统的实现),因此有时满足这些需求需要使用不同的命名空间。
通过非直观和/或深度嵌套的命名空间来挖掘你想要的变量肯定是痛苦的,如果你可能需要使用几个定义相同标识符的“使用命名空间”效果较差,但是可以适合更多模态代码,这些代码往往会更多地使用一个或另一个命名空间。
因此,在决定是否将每个文件夹的代码(或其他逻辑上不同的组)放入不同的名称空间时,您可能需要考虑这些因素。
答案 3 :(得分:0)
没有理由不真正帮助人们阅读您的代码。有些事需要注意:
答案 4 :(得分:0)
您可以随意排列文件;您只需要调整构建工具的包含路径和源路径即可匹配。
为每个目录提供它自己的命名空间是过度的,可能是一个坏主意,因为它会使代码混乱。我建议每个项目最多使用一个命名空间,甚至每个公司只建一个命名空间(因为大概在公司内部,你有权在必要时重命名以解决名称冲突。命名空间的主要目的是处理两个代码库的情况)在两个不同组织的控制下,两者都使用相同的名称,而您作为第三方希望在同一个项目中使用它们,但无法修改任何代码库。)
答案 5 :(得分:0)
src /是c / c ++程序员将其源代码放在项目根目录中的常见位置。 例如:
doc/ <- documentation
libs/ <- additional libraries
po/ <- gettext translations
src/ <- sources
在src /下面创建子目录很常见,如果你有很多源文件,但是如何组织这个子结构没有限制。
请记住,c ++中的目录结构完全是可选的。这与c ++名称空间和目录结构之间没有联系。