匿名namespace的作用以及它与static的区别

一。匿名namespace的作用

在C语言中，如果我们在多个tu（translation unit）中使用了同一个名字做

为函数名或者全局变量名，则在链接阶段就会发生重定义错误，为了解决这个

问题，我们可以在定义这些标识符 （identifier）的时候加上static关键字修

饰以限制它只在一个tu范围内可见。

C++继承了C语言中static关键字的 这个用途，我们依旧可以使用static来避免

多个tu中使用同一个标识符带来的重定义问题。此外C++还提供了另一种特有

的方式，那就 是匿名namespace：一个没有指定名字的namespace被称为一个匿

名namespace；在一个tu中可以出现多个匿名 namespace，并且相同层次的匿名

namespace实际上被合成为同一个；出现在不同tu的匿名namespace中的相同标

识 符相互独立不会发生冲突，因此我们可以把那些只希望在同一个tu范围可见

的全局标识符放入一个匿名namespace中，效果与前面加 static相同。

 

二。匿名namespace与static的区别

一个全局标识符被static修饰后它的linkage变为 internal linkage，这就是

为什么不同tu中的相同标识符不会发生冲突的原因。

而匿名namespace却并不会改变在它 内部定义的标识符的linkage，它用来避免

名字冲突所采用的手段同C++用来实现重载的手段一摸一样，就是使用名字改

编（name mangling）：根据C++标准7.3.1.1，每个tu中的匿名namespace实际

上会拥有一个独一无二的名字，因此在不同tu的匿名 namespace中相同的标识

符实际上属于不同的namespace，自然在名字改编后就不会发生冲突了：

[quote

7.3.1.1 Unnamed namespaces [namespace.unnamed]

An unnamed-namespace-definition behaves as if it were replaced by

        namespace unique { }

        using namespace unique;

        namespace unique { namespace-body }

where all occurrences of unique in a translation unit are replaced

by the same identifier and this identifier differs from all other

identifiers in the entire program.

end quote]

为什么匿名namespace不采取跟static一样的做法呢，搞个新花 样岂不是增加

了编译器开发的负担？这其实是因为另一个C++的特性牵制了匿名namespace的

实现，那就是模板非类型参数 （template non-type arguments）：

[quote

14.3.2 Template non-type arguments [temp.arg.nontype]

A template-argument for a non-type, non-template template-parameter

shall be one of:

— an integral constant-expression of integral or enumeration type; or

— the name of a non-type template-parameter; or

— the address of an object or function with external linkage, including

   function templates and function template-ids but excluding non-static

   class members, expressed as & id-expression where the & is optional

   if the name refers to a function or array, or if the corresponding

   template-parameter is a reference; or

— a pointer to member expressed as described in 5.3.1 .

end quote]

正是被红字标出的external linkage这一需求限制了匿名namespace的实现！

试想一下，假如我们有一个全局对象或者函数只希望它在一个tu中有效，又

希 望能够用它的地址来实例化一个模板，怎么办？只在一个tu中有效，可以

选择internal linkage，但是要用它的地址做为模板参数，又要求它必须要

是external linkage！！

很显然，匿名namespace 不改变其内部标识符的linkage这一性质解决了这一

难题，我们可以把这个全局对象或者函数放心的扔在一个匿名namespace中，

然 后用它的地址来实例化一个模板，绝对不会发生重定义错误:)

 

现在大部分C++书籍都认为匿名namespace和static是相同的， 而正如这里所阐

述的，它们之间差异是明显的：static修饰的标识符由于internal linkage的

限制，是不能用来实例化模 板的！

 

 

最后给出一个例子证实匿名namespace确实不改变linkage，呵呵

代码中验证了external linkage/internal linkage/no linkage三种情况

---------------------------------------------------------

template <char *p>

struct foo

{

  void bar();

};

 

static char a ='a';

 

namespace

{

  char b = 'b';

  static char c = 'c';

 

  template <class T> struct xxx {};

 

  void foobar()

  {

    struct no_linkage {};

    xxx<no_linkage>();  // 如果编译错误，说明no_linkage的linkage没有变化

  }

}

 

int main()

{

  foo<&a>().bar();  // 由于a的linkage是internal，因此应该编译错误

  foo<&b>().bar();  // 如果编译正确，说明b的linkage是external

  foo<&c>().bar();  // 如果编译错误，说明c的linkage是internal

 

  foobar();

 

  return 0;

}

 

匿名 namespace 的不利之处

在工程实践中，匿名 namespace 有两大不利之处：

其中的函数难以设断点，如果你像我一样使用的是 gdb 这样的文本模式 debugger。

使用某些版本的 g++ 时，同一个文件每次编译出来的二进制文件会变化，这让某些 build tool 失灵。