《Effective C++》条款26 防卫潜伏的ambiguity模棱两可的状态

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

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

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），但在了解了导致经常产生潜在二义性的那些情况后，你就可以在软件设计和开发中将它出现的可能性降到最低。