Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!janus.Berkeley.EDU!jbuck
From: jbuck@janus.Berkeley.EDU (Joe Buck)
Newsgroups: comp.arch
Subject: Re: Instruction Scheduling
Message-ID: <41785@ucbvax.BERKELEY.EDU>
Date: 17 Apr 91 18:38:09 GMT
References: <20632@cbmvax.commodore.com> <MEISSNER.91Apr16121331@curley.osf.org> <24130@as0c.sei.cmu.edu>
Sender: nobody@ucbvax.BERKELEY.EDU
Organization: U.C. Berkeley
Lines: 49

In article <24130@as0c.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>In article <MEISSNER.91Apr16121331@curley.osf.org> meissner@osf.org (Michael Meissner) writes:
>
>[linker optimisation of function calls]
>
>>Except of course if you are using object oriented techniques, and are
>>calling through a function pointer.  In which case, the linker has to
>>fall back to the normal case of using fixed defaults.
>
>I don't understand the logic here.  Object oriented techniques are ways
>of designing code, not of implementing it.  I know of no evidence that
>OOD leads to code with greater dynamic functional variability than other
>techniques.

While it is true that some virtual function calls (to use C++ terminology)
can be eliminated, the use of function pointers is really an inevitable
part of true object oriented design, and there's no real loss of efficiency
by doing so: the extra overhead of the function pointer is traded off
against the extra overhead of a switch statement (we write far fewer
switch statements and less control logic in OO programs than the equivalent
non-OO programs).

For example the C function:

doSomethingTo (objPointer)
struct object * objPointer;
{
	switch (objPointer->type) {
		TYPE_A:	return doA(objPointer);
		TYPE_B: return doB(objPointer);
		...
		default: /* error */
}

is replaced in C++ by making "doSomethingTo" a virtual function, and the
switch statement is eliminated.  Existing code no longer needs to be
modified if a new type of object is added.

Since OO techniques also make incremental linking much easier, we really
do want the ability to add new code without modifying even the machine
code, so yes, we do want function pointers, and no, they are not going
away, and anyone designing a new architecture that doesn't handle
indirect function calls efficiently is really going to suffer in the
next few years, since indirect function calls are going to become more
common. 

--
Joe Buck
jbuck@janus.berkeley.edu	 {uunet,ucbvax}!janus.berkeley.edu!jbuck