Effective C++ 2e Item26

原创 2001年07月15日 18:28:00

条款26: 当心潜在的二义性

每个人都有思想。有些人相信自由经济学,有些人相信来生。有些人甚至相信COBOL是一种真正的程序设计语言。C++也有一种思想:它认为潜在的二义性不是一种错误。

这是潜在二义性的一个例子:

class B;                    // 对类B提前声明
                            //
class A {
public:
  A(const B&);              // 可以从B构造而来的类A
};

class B {
public:
  operator A() const;       // 可以从A转换而来的类B
};

这些类的声明没一点错——他们可以在相同的程序中共存而没一点问题。但是,看看下面,当把这两个类结合起来使用,在一个输入参数为A的函数里实际传进了一个B的对象,这时将会发生什么呢?

void f(const A&);

B b;

f(b);                       // 错误!——二义

一看到对f的调用,编译器就知道它必须产生一个类型A的对象,即使它手上拿着的是一个类型B的对象。有两种都很好的方法来实现(见条款M5)。一种方法是调用类A的构造函数,它以b为参数构造一个新的A的对象。另一种方法是调用类B里自定义的转换运算符,它将b转换成一个A的对象。因为这两个途径都一样可行,编译器拒绝从他们中选择一个。

当然,在没碰上二义的情况下,程序可以使用。这正是潜在的二义所具有的潜伏的危害性。它可以长时期地潜伏在程序里,不被发觉也不活动;一旦某一天某位不知情的程序员真的做了什么具有二义性的操作,混乱就会爆发。这导致有这样一种令人担心的可能:你发布了一个函数库,它可以在二义的情况下被调用,而你却不知道自己正在这么做。

另一种类似的二义的形式源于C++语言的标准转换——甚至没有涉及到类:

void f(int);
void f(char);

double d = 6.02;

f(d);                         // 错误!——二义

d是该转换成int还是char呢?两种转换都可行,所以编译器干脆不去做结论。幸运的是,可以通过显式类型转换来解决这个问题:

f(static_cast<int>(d));       // 正确, 调用f(int)
f(static_cast<char>(d));      // 正确, 调用f(char)

多继承(见条款43)充满了潜在二义性的可能。最常发生的一种情况是当一个派生类从多个基类继承了相同的成员名时:

class Base1 {
public:
  int doIt();
};
class Base2 {
public:
  void doIt();
};

class Derived: public Base1,     // Derived没有声明
               public Base2 {    // 一个叫做doIt的函数
  ...

};

Derived d;

d.doIt();                   // 错误!——二义

当类Derived继承两个具有相同名字的函数时,C++没有认为它有错,此时二义只是潜在的。然而,对doIt的调用迫使编译器面对这个现实,除非显式地通过指明函数所需要的基类来消除二义,函数调用就会出错:

d.Base1::doIt();            // 正确, 调用Base1::doIt

d.Base2::doIt();            // 正确, 调用Base2::doIt

这不会令很多人感到麻烦,但当看到上面的代码没有用到访问权限时,一些本来很安分的人会动起心眼想做些不安分的事:

class Base1 { ... };        // 同上

class Base2 {
private:
  void doIt();              // 此函数现在为private
};                          

class Derived: public Base1, public Base2
{ ... };                    // 同上

Derived d;

int i = d.doIt();           // 错误! — 还是二义!

对doIt的调用还是具有二义性,即使只有Base1中的函数可以被访问。另外,只有Base1::doIt返回的值可以用于初始化一个int这一事实也与之无关——调用还是具有二义性。如果想成功地调用,就必须指明想要的是哪个类的doIt。

C++中有一些最初看起来会觉得很不直观的规定,现在就是这种情况。具体来说,为什么消除“对类成员的引用所产生的二义”时不考虑访问权限呢?有一个非常好的理由,它可以归结为:改变一个类成员的访问权限不应该改变程序的含义。

比如前面那个例子,假设它考虑了访问权限。于是表达式d.doIt()决定调用Base1::doIt,因为Base2的版本不能访问。现在假设Base1的Doit版本由public改为protected,Base2的版本则由private改为public。

转瞬之间,同样的表达式d.doIt()将导致另一个完全不同的函数调用,即使调用代码和被调用函数本身都没有被修改!这很不直观,编译器甚至无法产生一个警告。可见,不是象你当初所想的那样,对多继承的成员的引用要显式地消除二义性是有道理的。

既然写程序和函数库时有这么多不同的情况会产生潜在的二义性,那么,一个好的软件开发者该怎么做呢?最根本的是,一定要时时小心它。想找出所有潜在的二义性的根源几乎是不可能的,特别是当程序员将不同的独立开发的库结合起来使用时(见条款28),但在了解了导致经常产生潜在二义性的那些情况后,你就可以在软件设计和开发中将它出现的可能性降到最低。

Effective C++ 目录

改变旧有的C习惯(Shifting from C to C++) 013 条款1:尽量以 const 和 inline 取代 #define 013 Prefer const and inline...
  • sunrise918
  • sunrise918
  • 2011年08月19日 17:34
  • 494

Effective C++ 2e Item3

条款3:尽量用new和delete而不用malloc和freemalloc和free(及其变体)会产生问题的原因在于它们太简单:他们不知道构造函数和析构函数。假设用两种方法给一个包含10个string...
  • lostmouse
  • lostmouse
  • 2001年06月29日 19:39
  • 873

Effective C++ 2e Item25

条款25: 避免对指针和数字类型重载快速抢答:什么是“零”?更明确地说,下面的代码会发生什么?void f(int x);void f(string *ps);f(0);               ...
  • lostmouse
  • lostmouse
  • 2001年07月15日 18:27
  • 697

Effective C++ 2e Item42

条款42: 明智地使用私有继承条款35说明,C++将公有继承视为 "是一个" 的关系。它是通过这个例子来证实的:假如某个类层次结构中,Student类从Person类公有继承,为了使某个函数成功调用,...
  • lostmouse
  • lostmouse
  • 2001年08月02日 19:18
  • 649

Effective C++ 2e Item7

条款7:预先准备好内存不够的情况operator new在无法完成内存分配请求时会抛出异常(以前的做法一般是返回0,一些旧一点的编译器还这么做。你愿意的话也可以把你的编译器设置成这样。关于这个话题我将...
  • lostmouse
  • lostmouse
  • 2001年07月02日 16:25
  • 931

Effective C++ 2e Item37

条款37: 决不要重新定义继承而来的非虚函数有两种方法来看待这个问题:理论的方法和实践的方法。让我们先从实践的方法开始。毕竟,理论家一般都很耐心。假设类D公有继承于类B,并且类B中定义了一个公有成员函...
  • lostmouse
  • lostmouse
  • 2001年07月30日 19:06
  • 579

Effective C++ 2e Item16

条款16: 在operator=中对所有数据成员赋值条款45说明了如果没写赋值运算符的话,编译器就会为你生成一个,条款11则说明了为什么你会经常不喜欢编译器为你生成的这个赋值运算符,所以你会想能否有个...
  • lostmouse
  • lostmouse
  • 2001年07月08日 19:36
  • 632

Effective C++ 2e Item49

条款49: 熟悉标准库C++标准库很大。非常大。难以置信的大。怎么个大法?这么说吧:在C++标准中,关于标准库的规格说明占了密密麻麻300多页,这还不包括标准C库,后者只是 "作为参考"(老实说,原文...
  • lostmouse
  • lostmouse
  • 2001年08月09日 22:32
  • 1047

Effective C++ 2e Item15

条款15: 让operator=返回*this的引用C++的设计者Bjarne Stroustrup下了很大的功夫想使用户自定义类型尽可能地和固定类型的工作方式相似。这就是为什么你可以重载运算符,写类...
  • lostmouse
  • lostmouse
  • 2001年07月08日 19:35
  • 666

Effective C++ 2e Item17

 条款17: 在operator=中检查给自己赋值的情况做类似下面的事时,就会发生自己给自己赋值的情况:class X { ... };X a;a = a;                     /...
  • lostmouse
  • lostmouse
  • 2001年07月09日 20:14
  • 634
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Effective C++ 2e Item26
举报原因:
原因补充:

(最多只允许输入30个字)