The Virtual Method Table (VMT) stores pointers to all the virtual methods declared for a class and its base classes. The layout of the VMT is the same as in most C++ implementations (including Borland C++ and C++ Builder) and is the same format required for COM, namely a list of pointers to methods. Each virtual method of a class or its ancestor classes has an entry in the VMT.

Each class has a unique VMT. Even if a class does not define any of its own virtual methods, but only inherits methods from its base class, it has its own VMT that lists all the virtual methods it inherits. Because each VMT lists every virtual method, Delphi can compile calls to virtual methods as quick lookups in the VMT. Because each class has its own VMT, Delphi uses the VMT to identify a class. In fact, a class reference is really a pointer to a class’s VMT, and the ClassType method returns a pointer to the VMT.

In addition to a table of virtual methods, the VMT includes other information about a class, such as the class name, a pointer to the VMT for the base class, and pointers to many other RTTI tables. The other RTTI pointers appear before the first virtual method in the VMT. Example 3-1 shows a record layout that is equivalent to the VMT. The actual list of virtual methods begins after the end of the TVmt record. In other words, you can convert a TClass class reference to a pointer to a TVmt record by subtracting the size of the record, as shown in Example 3-1.

type
  PVmt = ^TVmt;
  TVmt = record
    SelfPtr:            TClass;          // Points forward to the start
                                         //  of the VMT
    // The following pointers point to other RTTI tables. If a class
    // does not have a table, the pointer is nil. Thus, most classes
    // have a nil IntfTable and AutoTable, for example.
    IntfTable:          PInterfaceTable; // Interface table
    AutoTable:          PAutoTable;      // Automation table
    InitTable:          PInitTable;      // Fields needing finalization
    TypeInfo:           PTypeInfo;       // Properties & other info
    FieldTable:         PFieldTable;     // Published fields
    MethodTable:        PMethodTable;    // Published methods
    DynMethodTable:     PDynMethodTable; // List of dynamic methods

    ClassName:          PShortString;  // Points to the class name
    InstanceSize:       LongInt;       // Size of each object, in bytes
    ClassParent:        ^TClass;       // Immediate base class

    // The following fields point to special virtual methods that
    // are inherited from TObject.
    SafeCallException:  Pointer;
    AfterConstruction:  Pointer; 
    BeforeDestruction:  Pointer;
    Dispatch:           Pointer;
    DefaultHandler:     Pointer;
    NewInstance:        Pointer;
    FreeInstance:       Pointer;
    Destroy:            Pointer;

    // Here begin the virtual method pointers.
    // Each virtual method is stored as a code pointer, e.g.,
    // VirtualMethodTable: array[1..Count] of Pointer;
    // But the compiler does not store the count of the number of
    // method pointers in the table.
  end;
var
  Vmt: PVmt;
begin
  // To get a PVmt pointer from a class reference, cast the class
  // reference to the PVmt type and subtract the size of the TVmt
  // record. This is easily done with the Dec procedure:
  Vmt := PVmt(SomeObject.ClassType);
  Dec(Vmt);

As you can see, the VMT includes pointers to many other tables. The following sections describe these tables in more detail.

The only difference between a published declaration and a public one is that a published declaration tells the compiler to store information in the VMT. Only certain kinds of information can be stored, so published declarations face a number of restrictions:

The Classes unit declares TPersistent with the $M+ directive. TPersistent is usually used as a base class for all Delphi classes that need published declarations. Note that TComponent inherits from TPersistent.

type
  TMethodParam = packed record
    TypeInfo: PPTypeInfo;
    Name: ShortString;
    // The name is followed by a trailing #0 byte.
  end;
  TMethod = packed record
    Size: Word;                 // Size of the TVmtMethod record.
    Address: Pointer;           // Pointer to the method entry point.
    Name: packed ShortString;   // Name of the published method.
    // Some methods have an additional 4 zero bytes, which means the
    // method takes no parameters.
    // Some methods have an additional 6 bytes, followed by a series of
    // TMethodParam records, for each parameter.
    // It seems that only stdcall methods have this extra information.
    // You can identify the extra info by the TMethod.Size value being
    // too big for just the Size, Address, and Name members. The only
    // way to know how many parameters are stored here is to check
    // each parameter until you reach the record size.
    ExtraStuff: array[1..FourOrSix] of Byte;
    Params: array[1..ParamCount] of TMethodParam;
  end;
  { Published method table }
  TMethodTable = packed record
    Count: Word;
    Methods: array[1..Count] of TMethod;
  end;

type
  { Field class table }
  PFieldClassTable = ^TFieldClassTable;
  TFieldClassTable = packed record
    Count: Word;
    Classes: packed array[1..Count] of ^TClass;
  end;

  { Published field record }
  TField = packed record
    Offset: LongWord;   // Byte offset of field in the object. }
    ClassIndex: Word;   // Index in the FieldClassTable of the
                        // field's type.
    Name: packed ShortString;  // Name of the published field. }
  end;

  { Published field table }
  TFieldTable = packed record
    Count: Word;
    FieldClassTable: PFieldClassTable;
    Fields: packed array [1..Count] of TField;
  end;

constructor TStringDefault.Create(Owner:

TComponent);

begin

inherited;

if (Owner = nil) or

(([csReading, csDesigning] *

Owner.ComponentState) = [csDesigning])

then

StringProperty := 'Default value';

end;

The TypInfo unit declares several types and functions that give you easy access to the published properties of an object and other information. The Object Inspector relies on this information to perform its magic. You can obtain a list of the published properties of a class and get the name and type for each property. Given an object reference, you can get or set the value of any published property.

The TypeInfo function returns a pointer to a type information record, but if you don’t use the TypInfo unit, you cannot access anything in that record and must instead treat the result as an untyped Pointer. The TypInfo unit defines the real type, which is PTypeInfo, that is, a pointer to a TTypeInfo record. The type information record contains a type kind and the name of the type. The type kind is an enumerated value that tells you what kind of type it is: integer, floating point, string, etc.

procedure SetFontToArial10pt(Component: TComponent);
var
  Font: TFont;
  PropInfo: PPropInfo;
begin
  // First find out if the component has a Font property.
  PropInfo := GetPropInfo(Component, 'Font'),
  if PropInfo = nil then
    Exit;
  // Next see if the property has class type.
  if PropInfo.PropType^.Kind <> tkClass then
    Exit;
  Font := TFont.Create;
  try
    Font.Name := 'Arial';
    Font.Size := 10;
    // Now set the component's Font property.
    SetOrdProp(Component, PropInfo, Integer(Font));
    // SetOrdProp is just like Component.Font := Font except that
    // the compiler doesn't need to know about the Font property.
    // The component's writer copies the TFont object, so this
    // procedure must free its Font to avoid a memory leak.
  finally
    Font.Free;
  end;
end;

// Set the default value for all published properties.
procedure SetDefaultValues(Obj: TObject);
const
  tkOrdinal = [tkEnumeration, tkInteger, tkChar, tkSet, tkWChar];
  NoDefault = Low(Integer);
var
  PropList: PPropList;
  Count, I: Integer;
  Value: Integer;
begin
  // Count the number of ordinal properties that can have
  // default values.
  Count := GetPropList(Obj, tkOrdinal, nil);
  // Allocate memory to store the prop info & get the real prop list.
  GetMem(PropList, Count * SizeOf(PPropInfo));
  try
    GetPropList(Obj, tkOrdinal, PropList);
    // Loop through all the ordinal properties.
    for I := 0 to Count-1 do
      // If the property has a default value, set the property value
      // to that default.
      if PropList[I].Default <> NoDefault then
        SetOrdProp(Obj, PropList[I], PropList[I].Default)
  finally
    FreeMem(PropList);
  end;
end;

The VMT stores a list of pointers for virtual methods and another table in the VMT, which this section refers to as the dynamic method table, lists both dynamic methods and message handlers.

The compiler generates a small negative number for each dynamic method. This negative number is just like a message number for a message handler. To avoid conflicts with message handlers, the compiler does not let you compile a message handler whose message number falls into the range of dynamic method numbers. Once the compiler has done its work, though, any distinction between dynamic methods and message handlers is lost. They both sit in the same table and nothing indicates whether one entry is for a dynamic method and another is for a message handler.

The dynamic method table lists only the dynamic methods and message handlers that a class declares; it does not include any methods inherited from ancestor classes. The dynamic method table starts with a 2-byte count of the number of dynamic methods and message handlers, followed by a list of 2-byte method numbers, followed by a list of 4-byte method pointers. The dynamic method table is organized in this fashion (instead of having a list of records, where each record has a method number and pointer) to speed up searching for a method number. Example 3-6 shows the logical layout of a dynamic method table. As with the other tables, you cannot compile this record, because it is not real Pascal, just a description of what a dynamic method table looks like.

type
  TDynMethodTable = packed record
    Count: Word;
    Indexes: packed array[1..Count] of SmallInt;
    Addresses: packed array[1..Count] of Pointer;
  end;

Dispatching a message or calling a dynamic method requires a lookup of the method or message number in the Indexes array. The table is not sorted and the lookup is linear. Once a match is found, the method at the corresponding address is invoked. If the method number is not found, the search continues with the immediate base class.

The tradeoff between virtual and dynamic methods is that virtual method tables include all inherited virtual methods, so they are potentially large. Dynamic method tables do not list inherited methods, so they can be smaller. On the other hand, calling a virtual method is a fast index into a table, but calling a dynamic method requires a search through one or more tables.

In the VCL, dynamic methods are used only for methods that are called in response to user interactions. Thus, the slower lookup for dynamic methods will not impact overall performance. Also, the dynamic methods are usually declared in the root classes, such as TControl.

If you do not have a large class hierarchy, you will usually get smaller and faster code by using virtual methods instead of dynamic methods. After all, dynamic methods must store the method number in addition to the method address. Unless you have enough derived classes that do not override the dynamic method, the dynamic method table will end up requiring more memory than the virtual method table.

When Delphi constructs an object, it automatically initializes strings, dynamic arrays, interfaces, and Variants. When the object is destroyed, Delphi must decrement the reference counts for strings, interfaces, dynamic arrays, and free Variants and wide strings. To keep track of this information, Delphi uses initialization records as part of a class’s RTTI. In fact, every record and array that requires finalization has an associated initialization record, but the compiler hides these records. The only ones you have access to are those associated with an object’s fields.

A VMT points to an initialization table. The table contains a list of initialization records. Because arrays and records can be nested, each initialization record contains a pointer to another initialization table, which can contain initialization records, and so on. An initialization table uses a TTypeKind field to keep track of whether it is initializing a string, a record, an array, etc.

An initialization table begins with the type kind (1 byte), followed by the type name as a short string, a 4-byte size of the data being initialized, a 4-byte count for initialization records, and then an array of zero or more initialization records. An initialization record is just a pointer to a nested initialization table, followed by a 4-byte offset for the field that must be initialized. Example 3-7 shows the logical layout of the initialization table and record, but the declarations depict the logical layout without being true Pascal code.

type
  { Initialization/finalization record }
  PInitTable = ^TInitTable;
  TInitRecord = packed record
    InitTable: ^PInitTable;
    Offset: LongWord;        // Offset of field in object
  end;
  { Initialization/finalization table }
  TInitTable = packed record
  {$MinEnumSize 1} // Ensure that TypeKind takes up 1 byte.
    TypeKind: TTypeKind;
    TypeName: packed ShortString;
    DataSize: LongWord;
    Count: LongWord;
    // If TypeKind=tkArray, Count is the array size, but InitRecords
    // has only one element; if the type kind is tkRecord, Count is the
    // number of record members, and InitRecords[] has a
    // record for each member. For all other types, Count=0.
    InitRecords: array[1..Count] of TInitRecord;
  end;

The master TInitRecord for the class has an empty type name and zero data size. The type kind is always tkRecord. The Count is the number of fields that need initialization, and the InitRecords array contains a TInitRecord for each such member. Each initialization record points to an initialization table that contains the type kind and type name for the associated member. This organization seems a little strange, but you can soon grow accustomed to it.

Most types do not need initialization or finalization, but the following types do:

The automated section of a class declaration is now obsolete because it is easier to create a COM automation server with Delphi’s type library editor, using interfaces. Nonetheless, the compiler currently supports automated declarations for backward compatibility. A future version of the compiler might drop support for automated declarations.

The OleAuto unit tells you the details of the automated method table: The table starts with a 2-byte count, followed by a list of automation records. Each record has a 4-byte dispid (dispatch identifier), a pointer to a short string method name, 4-bytes of flags, a pointer to a list of parameters, and a code pointer. The parameter list starts with a 1-byte return type, followed by a 1-byte count of parameters, and ends with a list of 1-byte parameter types. The parameter names are not stored. Example 3-8 shows the declarations for the automated method table.

const
  { Parameter type masks }
  atTypeMask = $7F;
  varStrArg  = $48;
  atByRef    = $80;
  MaxAutoEntries = 4095;
  MaxAutoParams = 255;

type
  TVmtAutoType = Byte;
  { Automation entry parameter list }
  PAutoParamList = ^TAutoParamList;
  TAutoParamList = packed record
    ReturnType: TVmtAutoType;
    Count: Byte;
    Types: array[1..Count] of TVmtAutoType;
  end;
  { Automation table entry }
  PAutoEntry = ^TAutoEntry;
  TAutoEntry = packed record
    DispID: LongInt;
    Name: PShortString;
    Flags: LongInt; { Lower byte contains flags }
    Params: PAutoParamList;
    Address: Pointer;
  end;

  { Automation table layout }
  PAutoTable = ^TAutoTable;
  TAutoTable = packed record
    Count: LongInt;
    Entries: array[1..Count] of TAutoEntry; 
  end;

Any class can implement any number of interfaces. The compiler stores a table of interfaces as part of the class’s RTTI. The VMT points to the table of interfaces, which starts with a 4-byte count, followed by a list of interface records. Each interface record contains the GUID, a pointer to the interface’s VMT, the offset to the interface’s hidden field, and a pointer to a property that implements the interface with the implements directive. If the offset is zero, the interface property (called ImplGetter) must be non-nil, and if the offset is not zero, ImplGetter must be nil. The interface property can be a reference to a field, a virtual method, or a static method, following the conventions of a property reader (which is described earlier in this chapter, under Published Properties“). When an object is constructed, Delphi automatically checks all the interfaces, and for each interface with a non-zero IOffset, the field at that offset is set to the interface’s VTable (a pointer to its VMT). Delphi defines the types for the interface table, unlike the other RTTI tables, in the System unit. These types are shown in Example 3-9.

type
  PInterfaceEntry = ^TInterfaceEntry;
  TInterfaceEntry = record
    IID: TGUID;
    VTable: Pointer;
    IOffset: Integer;
    ImplGetter: Integer;
  end;

  PInterfaceTable = ^TInterfaceTable;
  TInterfaceTable = record
    EntryCount: Integer;
    // Declare the type with the largest possible size,
    // but the true size of the array is EntryCount elements.
    Entries: array[0..9999] of TInterfaceEntry;
  end;

TObject implements several methods for accessing the interface table. See Chapter 5 for the details of the GetInterface, GetInterfaceEntry, and GetInterfaceTable methods.

This chapter introduces you to a class’s virtual method table and runtime type information. To better understand how Delphi stores and uses RTTI, you should explore the tables on your own. The code that accompanies this book on the O’Reilly web site includes the Vmt.exe program. The VmtInfo unit defines a collection of interfaces that exposes the structure of all the RTTI tables. The VmtImpl unit defines classes that implement these interfaces. You can read the source code for the VmtImpl unit or just explore the Vmt program. See the VmtForm unit to add types that you want to explore, or to change the type declarations.

You can also use the VmtInfo interfaces in your own programs when you need access to the RTTI tables. For example, you might write your own object persistence library where you need access to a field class table to map class names to class references.

The interfaces are self-explanatory. Because they use Delphi’s automatic reference counting, you don’t need to worry about memory management, either. To create an interface, call one of the following functions:

function GetVmtInfo(ClassRef: TClass): IVmtInfo; overload;
function GetVmtInfo(ObjectRef: TObject): IVmtInfo; overload;
function GetTypeInfo(TypeInfo: PTypeInfo): ITypeInfo;

Use the IVmtInfo interface and its related interfaces to examine and explore the rich world of Delphi’s runtime type information. For example, take a look at the TFont class, shown in Example 3-10.

type
  TFont = class(TGraphicsObject)
  private
    FColor: TColor;
    FPixelsPerInch: Integer;
    FNotify: IChangeNotifier;
    procedure GetData(var FontData: TFontData);
    procedure SetData(const FontData: TFontData);
  protected
    procedure Changed; override;
    function GetHandle: HFont;
    function GetHeight: Integer;
    function GetName: TFontName;
    function GetPitch: TFontPitch;
    function GetSize: Integer;
    function GetStyle: TFontStyles;
    function GetCharset: TFontCharset;
    procedure SetColor(Value: TColor);
    procedure SetHandle(Value: HFont);
    procedure SetHeight(Value: Integer);
    procedure SetName(const Value: TFontName);
    procedure SetPitch(Value: TFontPitch);
    procedure SetSize(Value: Integer);
    procedure SetStyle(Value: TFontStyles);
    procedure SetCharset(Value: TFontCharset);
  public
    constructor Create;
    destructor Destroy; override;
    procedure Assign(Source: TPersistent); override;
    property FontAdapter: IChangeNotifier read FNotify write FNotify;
    property Handle: HFont read GetHandle write SetHandle;
    property PixelsPerInch: Integer read FPixelsPerInch
        write FPixelsPerInch;
  published
    property Charset: TFontCharset read GetCharset write SetCharset;
    property Color: TColor read FColor write SetColor;
    property Height: Integer read GetHeight write SetHeight;
    property Name: TFontName read GetName write SetName;
    property Pitch: TFontPitch read GetPitch write SetPitch
        default fpDefault;
    property Size: Integer read GetSize write SetSize stored False;
    property Style: TFontStyles read GetStyle write SetStyle;
  end;

Notice that one field is of type IChangeNotifier. The Changed method is declared as dynamic in the base class, TGraphicsObject. TFont has no published fields or methods, but has several published properties. Example 3-11 shows the VMT and type information for the TFont class. You can see that the dynamic method table has one entry for Changed. The Size property is not stored, but the other published properties are. The Vmt.exe program can show you the same kind of information for almost any class or type.

Vmt: 40030E78
  Destroy: 4003282C
  FreeInstance: 400039D8
  NewInstance: 400039C4
  DefaultHandler: 40003CAC
  Dispatch: 40003CB8
  BeforeDestruction: 40003CB4
  AfterConstruction: 40003CB0
  SafeCallException: 40003CA4
  Parent: 40030DA4 (TGraphicsObject)
  InstanceSize: 32
  ClassName: 'TFont'
  Dynamic Method Table: 40030EE2
    Count: 1
    40032854 (-3)
  Method Table: 00000000
  Field Table: 00000000
  TypeInfo: 40030EF4
  InitTable: 40030ED0
  TypeName: 
  TypeKind: tkRecord
  DataOffset: 0
  Count: 1
  RecordSize: 0
    [1]
    InitTable: 40030E44
    TypeName: IChangeNotifier
    TypeKind: tkInterface
    DataOffset: 28
  AutoTable: 00000000
  IntfTable: 00000000

type TFontCharset = 0..255; // otUByte
type TColor = -2147483648..2147483647; // otSLong
type Integer = -2147483648..2147483647; // otSLong
type TFontName; // tkLString
type TFontPitch = (fpDefault, fpVariable, fpFixed); // otUByte
type TFontStyle = (fsBold, fsItalic, fsUnderline, fsStrikeOut);
type TFontStyles = set of TFontStyle; // otUByte
type TObject = class // unit 'System'
end;
type TPersistent = class(TObject) // unit 'Classes'
end;
type TGraphicsObject = class(TPersistent) // unit 'Graphics'
end;
type TFont = class(TGraphicsObject) // unit 'Graphics'
published
  property Charset: TFontCharset read (static method 40032CD4)
    write (static method 40032CDC) nodefault stored True; // index 0
  property Color: TColor read (field 20) write (static method 400329AC)
    nodefault stored True; // index 1
  property Height: Integer read (static method 40032B8C)
    write (static method 40032B94) nodefault stored True; // index 2
  property Name: TFontName read (static method 40032BBC)
    write (static method 40032BD4) nodefault stored True; // index 3
  property Pitch: TFontPitch read (static method 40032CA4)
    write (static method 40032CAC) default 0 stored True; // index 4
  property Size: Integer read (static method 40032C30)
    write (static method 40032C4C) nodefault stored False; // index 5
  property Style: TFontStyles read (static method 40032C6C)
    write (static method 40032C78) nodefault stored True; // index 6
end;