Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!yale!cs.utexas.edu!usc!apple!apple.com!DEREK
From: DEREK@apple.com (Derek White)
Newsgroups: comp.lang.c++
Subject: Re: PolyMorphism (default? virtualness)
Message-ID: <8068@goofy.Apple.COM>
Date: 4 May 90 16:35:18 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer/ATG
Lines: 21
References:<1990Apr10.112351.24301@athena.mit.edu> <6170016@hpindda.HP.COM> <1204@calmasd.Prime.COM> <54226@microsoft.UUCP> <132@logo.procase.UUCP> <54370@microsoft.UUCP>

As has been discused in previous postings, virtual functions CAN be 
optimized by smart tools towards the end of the build cycle.  In the Mac's 
MPW Object Pascal environment, all member functions start out "virtual" 
(polymorphic), but the linker analyzes the object code and 
inheritance structure, deduces which methods are "leaf" methods, and 
generates direct calls to the method instead going through a method 
dispatcher (which is SLOW).  Note that it does this for the final program, 
not the libraries.  The MPW linker has been doing this for years.

CFront was designed to work with generic compilers, linkers, etc, but 
significant improvements can be made by designing a linker that could 
replace virtual calls to leaf member functions with direct functions, and 
strip vtables of references to these "leaf" virtual methods.  Environments 
that have shared object libaries would not be as optimizable, but it would 
still help.

There are still occassions when it would be useful to designate 
non-virtual functions.  My guess is that 99.9% of private member functions 
should be non-virtual, and that around 80%-90%? of protected/public member 
functions should be virtual if an optimizing scheme existed.  It starts to 
make a good case for changing the defaults.