Effective C++, 2E | Item 26: Guard against potential ambiguity Back to Item 25: Avoid overloading on a pointer and a numerical type.
Continue to Item 27: Explicitly disallow use of implicitly generated member functions you don't want.
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;                    // forward declaration for
// class B
class A {
public:
A(const 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<int>(d));       // fine, calls f(int)
f(static_cast<char>(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,          // Derived doesn't declare
public Base2 {         // 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();            // fine, calls Base1::doIt

d.Base2::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 { ... };        // same as above

class Base2 {
private:
void doIt();              // this function is now
};                          // private

class Derived: public Base1, public Base2
{ ... };                    // same as above

Derived d;

int i = d.doIt();           // error! stillambiguous!


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. Back to Item 25: Avoid overloading on a pointer and a numerical type.
Continue to Item 27: Explicitly disallow use of implicitly generated member functions you don't want.