Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!milton!uw-beaver!ssc-vax!bcsaic!mgates From: mgates@entiat.boeing.com (Michael Gates) Newsgroups: comp.lang.c++ Subject: Re: Multiple Inheritance Problem Message-ID: Date: 24 May 91 23:05:03 GMT References: <74462@brunix.UUCP> <2153@godzilla.tcs.com> <72495@microsoft.UUCP> Sender: nntp@bcsaic.UUCP Organization: Boeing Computer Services, Bellevue, WA Lines: 89 In-reply-to: ilanc@microsoft.UUCP's message of 22 May 91 15:22:58 GMT In article <72495@microsoft.UUCP> ilanc@microsoft.UUCP (Ilan CARON) writes: > mgates@entiat.boeing.com (Michael Gates) considers the following > "diamond" hierarchy: > > Object > Draw()=0; > Update()=0; > Dup()=0; > > Line : virtual Object Dependent : virtual Object > Draw(); Update(); > > DependentLine : Line, Dependent > Dup() { new DependentLine; } > and says that: > > > G++ 1.39 compiles this with no trouble at all, which is > >correct. For each pure virtual function, there is a path from > >DependentLine to Object which defines that function. The ARM section > >10.1.1 addresses this issue under the topic of name dominance. > > > > [ARM def of dominance omitted] > > > >Here Line::Draw dominates the Object::Draw that is also inherited > >by DependentLine. Also Dependent::Update dominates Object::Update. > > While the above is true, it is irrelevant. > > Dominance is an ambiguity resolution rule (IMHO of only marginal value), > that is used in resolving client code references to names. It says > nothing about how to *construct* an object -- in particular, it says > nothing wrt virtual function table contents. It is relevant to the extent that it is the only part of the ARM that *comes close* to addressing the problem. Since it is not explicitly laid to rest anywhere in the book, I certainly have no trouble changing my "which is correct" to "which is reasonable (IMHO)". The reasonableness and probable correctness is supported by section 10.10c, pages 233-235. I will explain after this quote. > As I pointed out in a previous posting (I believe): > > > You might think that it should prefer the implementation as opposed to > > the pure virtual definition -- but on reflection that doesn't make > > much sense. Consider this fragment: > > > > Line *pLine = new DependentLine; > > pLine->Update(); // ??? use Dependent::Update() ??? > ^^^^^^^^^^^^^^^^ > What does G++ do with this -- never-never-land? (I suppose Michael > might be thinking that this is a programmer bug). No, G++ *does* use Dependent::Update(). This is what it is supposed to do, per the second half of page 234: example (showing above behaviour) followed by "A call to a virtual function through one path in an inheritance structure may result in the invocation of a function redefined on another path. This is an elegant way for a base class to act as a means of communication between sibling classes, such as..." Clearly the dominance rule (or something similar) is being used to determine the contents of the final (DependentLine) vtable. In the example in the ARM, the final class (DependentLine here, BMW in the book) can get to the virtual base's "Update" (g() in the book) directly, can get to the virtual base's "Update" through "Line" (BW in the book), and can get to the redefined "Update" of "Dependent" (MW in the book). The latter is chosen to place in the final vtable. The reason I say "dominance rule (or something similar)" above is on page 235, 2nd paragraph: "To avoid ambiguous function definitions, all redefinitions of a virtual function from a virtual base must occur on a single path through the inheritence structure." Before anyone jumps up with > Note that the issue is not how to resolve references to names in the > scope of DependentLine, rather whether DependentLine is an abstract > class or not (since we're trying to construct an instance of it). let me point out that the ARM section in question is discussing how to build vtables. Unfortunately the case of pure virtual functions is not dealt with. In absence of direction, why should they be treated differently? -- et tu mgates?