On Jan 20, 2006, at 8:24 AM, John Love-Jensen wrote:
The case you pointed out is a truly ambiguous case.
I finally found the answer I was looking for--the rationale for the
ambiguity and how to preserve the abstraction of the interface.
- ss15.2.2 Inheritance and Using-Declarations (kudos to Dima for
the concrete reference!)
You, the programmer, can disambiguate it by explicitly designating
what you
want the child class to do.
Kinda blows apart the whole concept of public inheritance, doesn't
it?
No. It protects the developer from unexpected behavior and surprises.
As a developer, I'd be highly upset if the introduction of a new
base class
all of a sudden silently changed the behavior of the class in use
because
two symbols happened to collide and then the compiler decided on
its own
that the other symbol was a better signature match.
I _received_ an unexpected surprise. C++ provides two ways to
resolve the issue:
A. have the caller explicitly reach down into the class to
disambiguate--rather messy for the caller and breaks abstraction.
B. force the overloading scope into alignment with the class
interface with an explicit "using-declaration".
I find neither of these particularly appealing, but the latter
preserves abstraction. We'll see how it works with method templates.
IMO, having the caller do the disambiguation is particularly
objectionable because re-implementing M to/from something like:
>>>>>>>>>>>>
class M {
public:
void f(int);
void f(double);
};
<<<<<<<<<<<<
could unexpectedly make or break client code. That's pretty serious,
because "You always know who you call. You never know who calls you."
