Item 26: Guard against potential ambiguity.

Item 26: Guard against potential ambiguity.
Everybody has to have a philosophy. Some people believe in laissez faire economics, others believe in
reincarnation. Some people even believe that COBOL is a real programming language. C++ has a philosophy,
too: it believes that potential ambiguity is not an error.
Here's an example of potential ambiguity:
class B;
class A {
public:
A(const B&);
// forward declaration for
// class B
// an A can be
// constructed from a B
};
class B {
public:
operator A() const;
// a B can be
// converted to an A
};
There's nothing wrong with these class declarations ? they can coexist in the same program without the slightest
trouble. However, look what happens when you combine these classes with a function that takes an A object, but
is actually passed a B object:
void f(const A&);
B b;
f(b);
// error! ? ambiguous
Seeing the call to f, compilers know they must somehow come up with an object of type A, even though what
they have in hand is an object of type B. There are two equally good ways to do this (see Item M5). On one
hand, the class A constructor could be called; this would construct a new A object using b as an argument. On
the other hand, b could be converted into an A object by calling the client-defined conversion operator in class
B. Because these two approaches are considered equally good, compilers refuse to choose between them.
Of course, you could use this program for some time without ever running across the ambiguity. That's the
insidious peril of potential ambiguity. It can lie dormant in a program for long periods of time, undetected and
inactive, until the day when some unsuspecting programmer does something that actually is ambiguous, at which
point pandemonium breaks out. This gives rise to the disconcerting possibility that you might release a library
that can be called ambiguously without even being aware that you're doing it.
A similar form of ambiguity arises from standard conversions in the language ? you don't even need any classes:
void f(int);
void f(char);
double d = 6.02;
f(d);
// error! ? ambiguous
Should d be converted into an int or a char? The conversions are equally good, so compilers won't judge.
Fortunately, you can get around this problem by using an explicit cast:
f(static_cast(d));
// fine, calls f(int)
f(static_cast(d));
// fine, calls f(char)
Multiple inheritance (see Item 43) is rife with possibilities for potential ambiguity. The most straightforward
case occurs when a derived class inherits the same member name from more than one base class:
class Base1 {
public:
int doIt();
};
class Base2 {
public:
void doIt();
};
class Derived: public Base1,
public Base2 {
...
// Derived doesn't declare
// a function called doIt
};
Derived d;
d.doIt();
// error! ? ambiguous
When class Derived inherits two functions with the same name, C++ utters not a whimper; at this point the
ambiguity is only potential. However, the call to doIt forces compilers to face the issue, and unless you
explicitly disambiguate the call by specifying which base class function you want, the call is an error:
d.Base1::doIt();
d.Base2::doIt();
// fine, calls Base1::doIt
// fine, calls Base2::doIt
That doesn't upset too many people, but the fact that accessibility restrictions don't enter into the picture has
caused more than one otherwise pacifistic soul to contemplate distinctly unpacifistic actions:
class Base1 { ... };
class Base2 {
private:
void doIt();
};
// same as above
// this function is now
// private
class Derived: public Base1, public Base2
{ ... };
// same as above
Derived d;
int i = d.doIt();
// error! ? still ambiguous!
The call to doIt continues to be ambiguous, even though only the function in Base1 is accessible! The fact that
only Base1::doIt returns a value that can be used to initialize an int is also irrelevant ? the call remains
ambiguous. If you want to make this call, you simply must specify which class's doIt is the one you want.
As is the case for most initially unintuitive rules in C++, there is a good reason why access restrictions are not
taken into account when disambiguating references to multiply inherited members. It boils down to this: changing
the accessibility of a class member should never change the meaning of a program.
For example, assume that in the previous example, access restrictions were taken into account. Then the
expression d.doIt() would resolve to a call to Base1::doIt, because Base2's version was inaccessible. Now
assume that Base1 was changed so that its version of doIt was protected instead of public, and Base2 was
changed so that its version was public instead of private.
Suddenly the same expression, d.doIt(), would result in a completely different function call, even though neither
the calling code nor the functions had been modified! Now that's unintuitive, and there would be no way for
compilers to issue even a warning. Considering your choices, you may decide that having to explicitly
disambiguate references to multiply inherited members isn't quite as unreasonable as you originally thought.
Given that there are all these different ways to write programs and libraries harboring potential ambiguity,
what's a good software developer to do? Primarily, you need to keep an eye out for it. It's next to impossible to
root out all the sources of potential ambiguity, particularly when programmers combine libraries that were
developed independently (see also Item 28), but by understanding the situations that often lead to potential
ambiguity, you're in a better position to minimize its presence in the software you design and develop.