Delphi Language Guide Delphi for Microsoft Win32 Delphi for the Microsoft. Net framework

part of the record type. That is, a variant has the form
fieldList1: type1;
  ...
fieldListn: typen;
where each fieldList is a valid identifier or comma-delimited list of identifiers, each type denotes a type, and the final
semicolon is optional. The types must not be long strings, dynamic arrays, variants (that is, Variant types), or
interfaces, nor can they be structured types that contain long strings, dynamic arrays, variants, or interfaces; but
they can be pointers to these types.
Records with variant parts are complicated syntactically but deceptively simple semantically. The variant part of a
record contains several variants which share the same space in memory. You can read or write to any field of any
variant at any time; but if you write to a field in one variant and then to a field in another variant, you may be overwriting
your own data. The tag, if there is one, functions as an extra field (of type ordinalType) in the non-variant part of the
record.
Variant parts have two purposes. First, suppose you want to create a record type that has fields for different kinds
of data, but you know that you will never need to use all of the fields in a single record instance. For example,
type
   TEmployee = record
      FirstName, LastName: string[40];
      BirthDate: TDate;
      case Salaried: Boolean of
        True: (AnnualSalary: Currency);
        False: (HourlyWage: Currency);
   end;
The idea here is that every employee has either a salary or an hourly wage, but not both. So when you create an
instance of 
TEmployee
, there is no reason to allocate enough memory for both fields. In this case, the only difference
between the variants is in the field names, but the fields could just as easily have been of different types. Consider
some more complicated examples:
84

---

type
  TPerson = record
    FirstName, LastName: string[40];
    BirthDate: TDate;
    case Citizen: Boolean of
        True: (Birthplace: string[40]);
        False: (Country: string[20];
                EntryPort: string[20];
                EntryDate, ExitDate: TDate);
  end;
type
  TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other);
  TFigure = record
    case TShapeList of
         Rectangle: (Height, Width: Real);
         Triangle: (Side1, Side2, Angle: Real);
         Circle: (Radius: Real);
         Ellipse, Other: ();
  end;
For each record instance, the compiler allocates enough memory to hold all the fields in the largest variant. The
optional tag and the constantLists (like 
Rectangle
, 
Triangle
, and so forth in the last example) play no role in the
way the compiler manages the fields; they are there only for the convenience of the programmer.
The second reason for variant parts is that they let you treat the same data as belonging to different types, even in
cases where the compiler would not allow a typecast. For example, if you have a 64-bit Real as the first field in one
variant and a 32-bit Integer as the first field in another, you can assign a value to the Real field and then read back
the first 32 bits of it as the value of the Integer field (passing it, say, to a function that requires integer parameters).