Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c++
Subject: Re: address of virtual function (revisited)
Message-ID: <11512@ulysses.homer.nj.att.com>
Date: 10 May 89 03:07:57 GMT
References: <904@garya.Solbourne.COM> <6590118@hplsla.HP.COM>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: jss@hector.UUCP (Jerry Schwarz)
Organization: AT&T Bell Laboratories
Lines: 70

In article <6590118@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:

   class B {
   public
   	const size_t	size ;
   	B(int i) : size(i) { }  ;
   }  ;
   
   class D : B {
   	D(...) : B(sizeof(D)) { ... } 
   } ;
   
   	B* p ; ...  p->size ... ; 

>Again, the complaint is that virtual functions [as presently implemented
>in cfront with a pretty good backend C compiler] is too expensive
>relative to these simple lookups.  

And my point is that C++ puts into the programmers hands the tools
needed to generate whatever balance of lookup versus function calls
is desired.

>
>So, for example, right now, with my combination of cfront and
>back end compiler, Jerry's approach, where you violate the encapsulation
>of an object, access its instance variables directly, and lock
>future derived classes into using one approach to returning
>"size", 

The design of classes that you intend to use as base classes is
definitely non-trivial.  The decision to "lock in" the derived
classes in order to generate direct lookups for size, is a design
decision that should be weighed carefully.  I was illustrating how to
implement it once it had been made. I'd like to emphasize this point,
because I find it frequently overlooked.

**********************************
 The design of the "protected interface", which is what I call the
 interface between the base class and derived classes,  requires
 careful consideration.  One of C++ strengths is that it provides
 flexibility in specifying this interface. Consequently there is an
 obligation on the C++ programmer to use the flexibility wisely.
**********************************

>and force a syntax of p->size rather than p->size() --

That was simply an omission to save a couple of lines in the example
that I thought were irrelevant to the issues being discussed. What I
would consider good style is something like

	class B {
	public:	size_t	size() { return x_size ; }
	protected:
		B(int i) : x_size(i) {  } 
	private: 
		size_t	x_size { }
	} ;

Using C++ I can cause code to be generated as a direct lookup or as
an indirect function call.  Perhaps I've overlooked something. If Jim
suggests an alternative kind of code I'll try to figure out a way to
get it generated.  I don't see how any amount of optimization in a
compiler can do anything better unless the indirect function call is
speeded up. A machine in which a virtual function call takes 20X a
load is not a machine designed to run C++ code efficiently.
Personally, I think his complaint is with the hardware designers.
Maybe this discussion should be redirected to comp.arch :-)

Jerry Schwarz
AT&T Bell Labs, Murray Hill