不必要地使用未命名的命名空间C++

FCR*_*FCR 6 c++ namespaces anonymous unnamed-namespace

我一直在公司里看到这样的代码:

namespace {

const MAX_LIMIT = 50;
const std::string TOKEN = "Token";

}
Run Code Online (Sandbox Code Playgroud)

我很困惑,为什么你需要一个匿名命名空间.一方面,您需要MAX_LIMITAND 的本地翻译单元TOKEN.但是,由于这个原因,没有匿名命名空间就已经实现了const.static const而且简单const都实现了本地翻译单元.

另一方面,如果文件中的某个地方有一个名为相同的变量,则没有命名冲突.

int foo()
{
std::string TOKEN = "MyToken"; // Clash! ::TOKEN vs TOKEN can be used.
}
Run Code Online (Sandbox Code Playgroud)

这将证明匿名命名空间的合理性.但是,您在函数中需要一个变量名称的频率实际上是在函数const外部声明的变量吗?我的回答永远不会.所以在实践中,对我来说不需要未命名的命名空间.任何提示?

M.M*_*M.M 5

namespace当你解释时,这是多余的.你可以删除namespace {和匹配 }.

一个区别是你可以有不同的名字::TOKENunnamed_namespace::TOKEN.但这可能只是增加了混乱,并且最好得到编译错误.

不确定帖子的后半部分是什么,局部变量TOKEN阴影::TOKENunnamed_namespace::TOKEN.所以这种改变对那种情况没有任何影响.


eer*_*ika 3

在这种特殊情况下,命名空间确实是多余的,因为 const 命名空间作用域变量默认情况下确实具有内部链接。

考虑稍后更改代码的可能性。也许变量之一毕竟不应该是 const 。但使其成为非 const 也会更改默认链接。即使在进行此类更改后,匿名命名空间仍将保持内部链接。换句话说,匿名名称空间分离了对常量性和链接的关注。这是否是一件好事,取决于具体情况。

请注意,使用static关键字可以实现同样的效果。由于这与 anon 命名空间具有完全相同的效果,因此选择主要是出于审美考虑,因此基于意见。

使用匿名命名空间的一个论点static可能是一致性。您不能定义具有内部链接的类型static。由于某些内部符号(类型)无法在匿名命名空间之外定义,因此您可以约定在匿名命名空间中定义所有内部符号。当然,这种惯例——正如通常的惯例一样——是一个品味问题。

你的第二个反驳论点似乎是在反对不存在的差异。匿名命名空间对于函数作用域内的名称隐藏没有影响。