2008-11-06 131 views
2

我认为大多数C++程序员会同意污染全局命名空间是一个坏主意,但有时这个规则可以被忽略吗?污染全局命名空间

例如,我有一个类型,我需要使用所有在特定的应用程序 - 我应该这样定义它:

mytypes.h 

typedef int MY_TYPE; 

foo.cpp 

MY_TYPE myType; 

或者使用一个命名空间:

mytypes.h 

namespace ns { 
typedef int MY_TYPE; 
} 

foo.cpp 

ns::MY_TYPE myType; 
... 
using namespace ns; 
MY_TYPE myType; 

哪一种你喜欢哪一种?有时可以使用第一种方法吗?

回答

4

我使用命名空间来分割来自应用程序特定代码的库代码,并在一个大项目中对组成项目的各个模块进行分区。

全局名称空间因此对应用程序中跨多个模块使用的特定于应用程序的类型和函数很有用。

因此,如果您的应用程序中使用了MY_TYPE,请将其放入全局名称空间,否则将其放入命名空间中。

+0

我大多数人都同意,但如果在整个应用程序中使用MY_TYPE,我认为它可能会更好地作为单独模块/库的一部分提供服务。 – 2008-11-06 09:20:50

3

我不同意使用全局命名空间(当然,除了main之外)。对于整个应用程序中使用的内容,只需在.cpp文件的顶部使用using namespace即可,在所有相关的#include行之后。

+1

让我们不要走到极端:从根本不使用命名空间到不使用全局命名空间恕我直言。全局命名空间就是 - 命名空间。类似于MFC类的CObject;)它也可能很有用。 – 2008-11-06 08:17:59

7

您可以在一个单独的命名空间中定义的类型,并使用

using ns::MY_TYPE; 
4

图书馆不得,应用程序可能。

当多个人在应用程序上工作时,当然你需要清晰的规则,最清晰的规则是“不”。但是,这在所有情况下都不理想。

“使用”语句应该只在CPP文件的顶部,而不是在头文件中 - 但是这会使编写模板变得复杂 - 对于不久的将来大多数编译器而言 - 他们需要驻留在头文件中。根据我的经验(大多数是一个规模很大但分散程度很好的小团队),命名空间污染并不是什么大问题,只要您控制各自的代码并坚持使用描述性名称即可。我记得的情况很少,很容易处理。不过,第三方库存在主要问题 - 即使可用源代码也是如此。

YMMV与一个庞大的团队或一个巨大的项目,进入一个单一的编译。