Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!ilanc
From: ilanc@microsoft.UUCP (Ilan CARON)
Newsgroups: comp.lang.c++
Subject: Re: Multiple Inheritance Problem
Message-ID: <72495@microsoft.UUCP>
Date: 22 May 91 15:22:58 GMT
References: <74462@brunix.UUCP> <2153@godzilla.tcs.com> <MGATES.91May15112133@entiat.boeing.com>
Reply-To: ilanc@microsoft.UUCP (Ilan CARON)
Organization: Microsoft Corp., Redmond WA
Lines: 54

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.

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).

>
> So, in conclusion, DependentLine is an abstract class because it   
> doesn't provide an explicit implementation for Draw() and Update().

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).

--ilan caron (uunet!microsoft!ilanc)