CSDN博客

img taodm

Guru of the Week 条款30:名称搜索

发表于2002/8/5 10:14:00  1166人阅读

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

0 0

相关博文

我的热门文章

img
取 消
img