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》。