Guru of the Week 条款30：名称搜索
GotW#30 名称搜索（Name Lookup）
难度：9.5 / 10
当你调用一个函数时，到底调的是哪一个？其答案取决于“名称搜索”，但你肯定会发现其细节非常令人吃惊。
问题
在下面的代码中，调用的是哪个函数？为什么？分析一下影响。
namespace A {
struct X;
struct Y;
void f( int );
void g( X );
}
namespace B {
void f( int i ) {
f( i ); // which f()?
}
void g( A::X x ) {
g( x ); // which g()?
}
void h( A::Y y ) {
h( y ); // which h()?
}
}
解答
在下面的代码中，调用的是哪个函数？为什么？
其中两个比较明确，但第三个需要精通C++的名称搜索规则－－尤其是Koenig lookup。
namespace A {
struct X;
struct Y;
void f( int );
void g( X );
}
namespace B {
void f( int i ) {
f( i ); // which f()?
}
这个f()调用的是它自己，并且是无穷递归。
在namespace A中也有一个f(int)的函数。如果B写了“using namespace A;”或“using A::f;”，那么A::f(int)将是寻找f(int)过程中的候选函数之一，那个“f(i)”调用将在A::f(int)和B::f(int)间造成二义性。因为B没有将A::f(int)带入它的空间范围，于是只有B::f(int)被考虑，所以调用没有歧义。
void g( A::X x ) {
g( x ); // which g()?
}
这个调用在A::g(X)和B::g(X)间有二义性。程序员必须用命名空间的名字明确限定调用哪个g()。
你也许开始会奇怪为什么需要这么做。毕竟，和f()一样，B没有用“using”指令将A::g(X)带入它的空间范围，所以，你可能认为只有B::g(X)可选。没说错吧？好吧，这是个事实，在名称搜索时的一条补充规则：
Koenig Lookup （简化版）
如果你给函数提供一个class类型的实参（此处是A::X类型的x），那么在名称搜索时，编译器将认为包含实参类型的命名空间中的同名函数为可选函数。
下面这个更复杂些，但实质是一样的。这是取自C++标准的例子：
namespace NS {
class T { };
void f(T);
}
NS::T parm;
int main() {
f(parm); // OK, calls NS::f
}
我于此处不深究Koenig lookup的必要性（要延伸你的思维的话，将“NS”用“std”代替，将“T”用“string”代替，而“f”用“operator<<”代替，然后再考虑流程）。在最后的“延伸读物”中寻找Koenig lookup的更多知识，以及它在名称隔离和分析类间依赖上的影响。必须承认Koenig lookup实际上是个好东西，你也必须了解它是如何工作的，因为它将在某个时候影响你写下的代码。
void h( A::Y y ) {
h( y ); // which h()?
}
}
没有其它的h(A::Y)函数，所以这儿的f()调用它自己，也是无穷递归。
虽然B::h()的原型是使用了namespace A中的一个类型，但这不影响名称搜索的结果，因为namespace A中没有符合h(A::Y)名称的函数。
分析影响
要之，namespace B中的代码的含义被完全独立的namespace A中申明的函数影响了，虽然B在简单地提及了一个在A中找到的类型以外，没干任何事情，甚至连“using”都没有！
这意味着，命名空间之间不象人们最初想象得那样毫无依赖关系。别急着谴责命名空间；命名空间之间的互不依赖还是很完美的，它们之间只用一个T类型建立联系。本期的GotW只是想指出这样一个特例，此时，命名空间不是密不透风的...并且，实际上，在这种情况下，命名空间不应该是密不透风的，“延伸读物”将展示这一点。
延伸读物
命名空间与Koenig lookup之间的影响远比我所展示的深远。想得知为什么Koenig lookup不是命名空间上的漏洞，以及它怎样影响我们分析class之间的依赖关系，参阅我在March 1998于C++ Report上发表的文章《What's In a Class - The Interface Principle》。
