Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c++
Subject: Re: address of virtual function (revisited)
Message-ID: <11516@ulysses.homer.nj.att.com>
Date: 11 May 89 04:27:05 GMT
References: <904@garya.Solbourne.COM> <6590119@hplsla.HP.COM>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: jss@hector.UUCP (Jerry Schwarz)
Organization: AT&T Bell Laboratories
Lines: 32

In article <6590119@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>
>I have no problem with C++ *the language*, it *can* be efficiently
>implemented on today's machine -- I just haven't yet seen a C++
>compiler that *does* implement major details of the language efficiently.

This was not at all clear from your earlier remarks (at least not to
me.)  My earlier notes were addressing language design issues, not
optimization issues.  Complaints about the quality of optimizations
of compilers ought to specify what compiler you're complaining about.

>
>The biggest disappointment so far is unnecessary expansion of
>inline virtual functions into table lookup + indirect function calls.
>

You may be happy to learn that the pre-release 2.0 does expand
virtual functions inline when it can determine the correct version.

	struct K { 	
		virtual int size() { return sizeof(K) ; } ;
	} ;

	void g() {
		K k ;
		int s = k.f() ; 
			// this is expanded into a simple
			// assignment in sizeof(struct K)
	}

Jerry Schwarz
AT&T Bell Labs, Murray Hill