From 8430253216893403562
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,db4807a3f0a1e742
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1994-07-20 09:31:26 PST
Newsgroups: comp.std.c++
Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!agate!darkstar.UCSC.EDU!news.hal.COM!decwrl!borland.com!pete
From: pete@genghis.interbase.borland.com (Pete Becker)
Subject: Re: Multiple inheritance and delete
Message-ID: <Ct8xyr.Ivq@borland.com>
Sender: news@borland.com (News Admin)
Organization: Borland International
References: <IMMEL.94Jul18092230@chord.centerline.com> <1994Jul20.044817.698@corona.com>
Date: Wed, 20 Jul 1994 16:04:03 GMT
Lines: 32

In article <1994Jul20.044817.698@corona.com>,
Peter Kron <pkron@corona.com> wrote:
>
>This problem is particularly nasty, but is typical of a larger class
>of problems due to semantics of "virtual". For example, the following:
>
>class Base
>	{public: void	memberFunction();};
>class Derived : public Base
>	{public: void	memberFunction();};
>	
>void function()
>	{
>	Derived	object;
>	Base	*pointer=&object;
>	object.memberFunction();	//Derived::method
>	pointer->memberFunction();	//Base::method
>	}
>
>Clearly this is not desirable behavior, but is a side effect of trying
>to minimize storage for vtables and pointers to them. The concept of
>polymorphism should imply that *objects* determine how they respond to
>member functions, not callers. But here the reverse is the case.
>

	Clearly, the design decision for this pair of classes was that they
are not polymorphic. That is not a language flaw, but a deliberate decision
on the part of the designer of these classes. If you want the call to
memberFunction() to be virtual, design your classes appropriately. Please don't
impose your design criteria on the rest of the world. "There are more things
in heaven and Earth, Horation, than are dreamt of in your philosophy."
	-- Pete