Re: multiple inheritance ambiguity question
"Francesco S. Carta"
You seem to miss how :: works and groups. And that is about finding
*names* only while you wanted them to linger on after the name was
selected.
10.1 [class.mi] 4:
"In such lattices, explicit qualification can be used to specify which
subobject is meant."
Where "such lattices" refers to this example, given in 10.1 [class.mi]
3:
-------
class L { public: int next; /* ... */ };
class A : public L { /* ... */ };
class B : public L { /* ... */ };
class C : public A, public B { void f(); /* ... */ };
-------
Right after the above sentence, the Standard continues with:
"The body of function C::f could refer to the member next of each L
subobject:
void C::f() { A::next = B::next; }
Without the A:: or B:: qualifiers, the definition of C::f above would
be ill-formed because of ambiguity (class.member.lookup)."
As you can see from the above wording, the qualification is not only
about names, but also, in such cases, about disambiguating subobjects.
Yes it is. Here A and B on the left of ::, being *distinct* types can do the
job.
In your examples you use the *same* type, that is not good to tell a
difference.
Notice that the above example, of course, works fine both
theoretically (under the Standard's light) and practically (it does
compile, indeed).
That example happens to have the identical structure of the example
given below, taken from TC++PL 3rd ed., read on please.
This really hit me, because TC++PL 3rd edition presents some examples
which seem really reasonable, but which are expected to be rejected by
the current Standard.
As far I I saw the examples they are nowhere identical to yours, and does
not have similar problems. And work fine with the standard too.
From TC++PL 3rd ed., 15.2.3:
-------
struct Link {
Link* next;
};
class Task : public Link {
// ...
};
class Displayed : public Link {
// ...
};
// this is given in 15.2.2:
class Satellite : public Task, public Displayed {
// ...
};
void mess_with_links(Satellite* p) {
p->Task::Link::next = 0;
p->Displayed::Link::next = 0;
}
-------
Ah, Bjarne really messed up the example, he certainly meant
p->Task::next = 0;
p->Displayed::next = 0;
that should work fine.
According to (my understanding of) the Standard, in both of these
expressions...
-------
p->Task::Link::next = 0;
p->Displayed::Link::next = 0;
-------
...the "naming class" is "Link" (that is, the nested class in the
qualification chain), and since a Satellite cannot be implicitly
converted into a Link, those expressions are ill-formed (according to
11.2 [class.access.base] 5).
Actually, the above example doesn't compile in Comeau Online.
Notice how Stroustrup uses a redundant qualification, while the
Standard doesn't - it disambiguates the call without putting L (the
equivalent of Link) in the qualification chain.
Yes, and that extra qual does nothing good to the example.
As I said in comp.std.c++: "It would be nice if implementations could
allow redundant qualifications in such cases, and it would be even
nicer if a multiple ambiguity such as the one of my example could be
resolved only by climbing the qualification chain, but that would mean
changing the wording in 11.2/4 [errata corrige: I meant to write
"11.2/5"], and I'm not going to propose it."
IMO it would be even nicer BY FAR if we just could use :: directly with
*instances* not just types. The compiler knows the type anyway. (with the
next standard it can be hacked together via decltype, still not noce as the
normal way.) Then it could be used to naturally solve problems like in your
example, and importantly, many real ones too.
I see little value in changing the existing way for a little artificial
gain, making it easier to work with hierarchies built on guidelines from the
'no-no list'.
By the way, I never said that that TC++PL example was identical to my
example - just in case...
Ok.