On Jan 14, 2007, at 6:47 AM, Daniel Stenning wrote:
In the new RB scheme - is it ONLY RB framework objects that now all
have
virtual methods for every method , or do also methods on OUR RB
code also
all get compiled/linked as virtual all the time - EVEN in methods
are never
overridden ?
There are two different concepts here.
The RB langauge defines methods to work in a certain way: you can
"override" an inherited method with a subclass method having the same
signature. We call this a "virtual" method scheme because that's the
term used for this behavior in C++. In C++, however, "virtual" is an
option; in RB, it's just part of the way all methods work.
There used to be a bug such that methods from the RB framework
library could not be overridden properly. This was hard to fix and
persisted for a long time. The switch from 5.5 to 2005r1 gave us a
chance to address the architectural problem that caused this issue.
In 2005r1 and later, all methods, no matter where they were defined,
respond in exactly the same way to overriding subclass methods.
The second thing you're talking about is a specific performance
optimization known as "call devirtualization". This is where the
compiler observes that a specific call target could not have been
overridden and uses that knowledge to generate a simpler call
sequence. The method, conceptually, is still virtual, since it
*could* be overridden; the compiler just takes advantage of its
knowledge about the structure of the program to generate less complex
code that will do the same job.
Generally speaking, RB does not have an optimizing compiler, and call
devirtualization is no exception. It is an interesting and somewhat
unusual optimization, since it relies on a type of whole-program
analysis, but it is by no means the first thing I would pursue in an
optimization system for RB. Its value is mostly in enabling other
optimizations to work more efficiently.
Mars Saxman
REAL Software
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
