Moving Beyond TList: Implementing Type-Safe Collections in Delphi

The Cost of Casting in Legacy Collections

For years, Delphi developers relied on TList or TObjectList to manage groups of items. Because these collections store TObject or Pointer types, every retrieval requires a manual typecast. This pattern introduces two primary risks: runtime EInvalidCast exceptions when the wrong object type is retrieved, and a cognitive load on the developer to remember exactly what the list contains.

The solution is the use of Generics, introduced in Delphi 2010. By parameterizing the collection type, you shift the responsibility of type checking from the runtime to the compiler, eliminating casts and preventing type-mismatch bugs before the code ever runs.

Type-Safe Containers with System.Generics.Collections

The System.Generics.Collections unit provides a suite of containers that mirror the functionality of legacy lists but with strict type enforcement. The most common replacements are TList<T> for ordered sequences and TDictionary<TKey, TValue> for key-value lookups.

Unlike some languages that use "type erasure" (where type information is removed at runtime), the Delphi compiler generates specific code for each instantiation of a generic type. If you declare a TList<Integer>, the compiler treats it as a specialized list for integers, ensuring that the performance remains identical to a manually written integer-specific list.

Practical Implementation: TList<T> vs. TObjectList

When moving from TObjectList to a generic equivalent, the most important decision is whether you need the list to own the objects it stores. A standard TList<T> does not automatically free the objects it contains when the list is destroyed.

To achieve the "ownership" behavior of the legacy TObjectList, you should use TObjectList<T>. This specialized generic class ensures that when an item is removed or the list is cleared, the object is automatically freed from memory.

Example: Implementing a Type-Safe Product Manager

uses
  System.Generics.Collections, System.SysUtils;

type
  TProduct = class
  public
    Name: string;
    Price: Double;
    constructor Create(const AName: string; APrice: Double);
  end;

  TProductManager = class
  private
    // TObjectList<T> handles the memory management of TProduct instances
    FProducts: TObjectList<TProduct>;
  public
    constructor Create;
    destructor Destroy; override;
    procedure AddProduct(const AName: string; APrice: Double);
    function FindProduct(const AName: string): TProduct;
  end;

Implementation Logic:

constructor TProductManager.Create;
begin
  // Initialize the list. The second parameter 'True' ensures the list owns the objects.
  FProducts := TObjectList<TProduct>.Create(True);
end;

procedure TProductManager.AddProduct(const AName: string; APrice: Double);
begin
  // No casting needed. The compiler knows FProducts only accepts TProduct.
  FProducts.Add(TProduct.Create(AName, APrice));
end;

function TProductManager.FindProduct(const AName: string): TProduct;
var
  LItem: TProduct;
begin
  // Using a simple loop for demonstration; TDictionary would be faster for large sets
  for LItem in FProducts do
    if LItem.Name = AName then
      Exit(LItem);
  Result := nil;
end;

Performance and Memory Trade-offs

Generics provide a "zero-overhead" abstraction. Because the compiler generates the specific implementation for the type used, there is no hidden performance penalty for the type safety. However, there are a few limitations to consider:

• Binary Compatibility: If you are distributing a compiled package (BPL) to users on older versions of Delphi (pre-XE), generic instantiations may not be compatible. You must ensure the library is rebuilt with the target compiler version.
• Code Bloat: Since the compiler generates a new version of the class for every unique type used (e.g., TList<Integer> and TList<String> are different internal types), extremely heavy use of generics across hundreds of different types can marginally increase the size of the resulting binary.

Verifying the Implementation

To verify that your generic collection is working as intended and not relying on hidden pointers, you can perform a size check in a simple console application:

1. Declare a TList<Integer> and a TList<Pointer>.
2. Use SizeOf() to compare the two.
3. If the sizes are identical, the compiler is not inserting additional type descriptors, confirming that you are getting the raw performance of a specialized collection.

Run these checks in a Release build to ensure that debug symbols are not skewing the memory footprint results.