Why does all this Generics code take up so much space?  Because generics aren’t actual code; they’re a template for creating actual code.  The compiler creates a new copy of the class for each instantiation of a generic class.  And this makes sense, to a certain extent.  You can’t reuse the same machine code implementation for, say, a TList<TMyObject> and a TList<IMyInterface>, because the interface version needs the compiler to generate the reference-counting code when working with the internal storage. Same for strings.  And records, integers and other value types need to be handled differently than objects and interfaces, which are reference types.  The compiler handles all that under the hood, and it makes our job a lot easier.

But… this has the side-effect of also making a bunch of silly, unnecessary copies.  For example, if you have a TList<TMyObject1> and a TList<TMyObject2>, the generated machine code for their routines will be identical, because there’s nothing in the difference between two classes that matters to TList<T>.  To illustrate, here’s a disassembly of the .Add methods of two different TList instantiations for two different class types.

Type 1:

53               push ebx
56               push esi
51               push ecx
8BF2             mov esi,edx
8BD8             mov ebx,eax
8B5308           mov edx,[ebx+$08]
42               inc edx
8BC3             mov eax,ebx
E856FDFFFF       call Generics + $43A074
8B4308           mov eax,[ebx+$08]
890424           mov [esp],eax
8B5304           mov edx,[ebx+$04]
893482           mov [edx+eax*4],esi
FF4308           inc dword ptr [ebx+$08]
33C9             xor ecx,ecx
8BD6             mov edx,esi
8BC3             mov eax,ebx
8B18             mov ebx,[eax]
FF5304           call dword ptr [ebx+$04]
8B0424           mov eax,[esp]
5A               pop edx
5E               pop esi
5B               pop ebx
C3               ret

Type 2:

53               push ebx
56               push esi
51               push ecx
8BF2             mov esi,edx
8BD8             mov ebx,eax
8B5308           mov edx,[ebx+$08]
42               inc edx
8BC3             mov eax,ebx
E856FDFFFF       call Generics + $43AC54
8B4308           mov eax,[ebx+$08]
890424           mov [esp],eax
8B5304           mov edx,[ebx+$04]
893482           mov [edx+eax*4],esi
FF4308           inc dword ptr [ebx+$08]
33C9             xor ecx,ecx
8BD6             mov edx,esi
8BC3             mov eax,ebx
8B18             mov ebx,[eax]
FF5304           call dword ptr [ebx+$04]
8B0424           mov eax,[esp]
5A               pop edx
5E               pop esi
5B               pop ebx
C3               ret

You can eyeball this, or paste it into BeyondCompare if you’d like, but they’re identical.  The only difference is in the CALL line; the disassembly shows a different offset on the right, because the two collection classes are each calling their own versions of GrowCheck.  But the actual machine code on the left is identical, because the CALL instruction uses a relative jump and the routines are arranged the same way in relation to each other.

This being true, it would be really nice if the Delphi linker understood this (it would have to be done in the linker, because you could have different instantiations of the same basic generic class in different units) and kept track of all the instantiations of each generic class and compared them against each other, method by method. When it found routines that were identical like this, it should strip out the duplicates and adjust call references, VMT slots, etc accordingly.

This would probably slow the linker down by a certain amount, and if it’s too slow there should probably be a compiler switch to disable it so it doesn’t interfere with coding productivity, but it’s certainly something I’d like to be have available when I’m making a release build.

The first thread goes through and pushes data into the queue however it wants to.  The second has it easy; all it has to do is loop endlessly until the queue is shut down.  And we all know how to do that:

for value in queue do
  process(value);

Except that if you try to do that, the compiler will complain at you.  There’s no enumerator.  For some strange reason, out of all the collections in Generics.Collections, TThreadedQueue<T> alone does not descend from TEnumerable<T>.

Oh well.  It’s not all that hard to add an enumerator to a class that doesn’t have one.  Just use a class helper.

TThreadedQueueEnumerator<T> = class
  private
    FQueue: TThreadedQueue<T>;
    FCurrent: T;
    function GetCurrent: T;
  public
    constructor Create(queue: TThreadedQueue<T>);
    property Current: T read GetCurrent;
    function MoveNext: Boolean;
  end;

  TThreadedQueueHelper<T> = class helper for TThreadedQueue<T>
  public
    function GetEnumerator: TThreadedQueueEnumerator<T>;
  end;

implementation

{ TThreadedQueueEnumerator<T> }

constructor TThreadedQueueEnumerator<T>.Create(queue: TThreadedQueue<T>);
begin
  FQueue := queue;
end;

function TThreadedQueueEnumerator<T>.GetCurrent: T;
begin
  result:= FCurrent;
end;

function TThreadedQueueEnumerator<T>.MoveNext: Boolean;
begin
  result := FQueue.PopItem(FCurrent) = wrSignaled;
end;

{ TThreadedQueueHelper<T> }

function TThreadedQueueHelper<T>.GetEnumerator: TThreadedQueueEnumerator<T>;
begin
  result := TThreadedQueueEnumerator.Create(self);
end;

Well, that was easy.  That’s probably the simplest enumerator I’ve ever written, because of the way the queue’s design makes it easy to implement MoveNext.  Except… that doesn’t compile either.  Apparently you can’t put generic type parameters on a class helper, which means that as far as I can tell, you can’t apply a class helper to a generic class at all.

I suppose I could subclass it and add the enumerator that way, but TEnumerableThreadedQueue<T> is a bit of a bulky name, don’t you think?  I have to wonder why the enumerator was left off of this collection, though, especially since the standard enumerator pattern is basically the only reasonable way to use a class like this…

The first thing I knew about the release was when I received my SA email yesterday afternoon, as opposed to having to wait a few days or even weeks to get my upgrade as has happened in previous years.  Big improvement there, and I hope Embarcadero keeps it up for subsequent releases. Good.

No OSX support, which we all thought was going to be in this release up until a few weeks ago. Bad. But it’s not there because the people at Embarcadero preferred to focus on quality and not release something that wasn’t ready. Good. No one wants to see (or pay for) another D8.

So I open it up and start browsing through some code.  My settings from D2010 didn’t get migrated forward. Annoying. There really should be some way to import them as part of the installation process.

ErrorInsight is the same old same old, with false positives all over the place because it can’t find basic standard library units. Annoying. But at least it doesn’t choke on methods of objects from a generic list anymore. Good.

Speaking of Generics, huge improvement here.  I was able to go through my codebase and remove all the annoying workarounds for generics-related glitches, and it compiles and runs properly now! Good.

When it’s time to debug, I immediately noticed a few improvements.  We finally, finally, after all these years, have debug DCPs available for the standard libraries.  (For those not familiar with them, DCPs are to Delphi packages as DCUs are to units.)  That means that people like me who build stuff with packages are able to trace into the RTL when debugging.  Good.

Also, something that always drove me up the wall about the debugger has been fixed.  When you put the cursor in an expression and hit CTRL-F7, it pops up the Evaluate/Modify window and evaluates whatever you had the cursor on.  But if you moved the cursor and hit CTRL-F7 again without closing the Evaluate/Modify window, it would focus the Evaluate/Modify window, but it wouldn’t evaluate the new expression you had selected.  You’d have to close the window and hit CTRL-F7 again to get a new evaluation.  (Or copy/paste or type it in, of course.)  That always bugged me, but it’s been fixed in XE.  Good.

And while we’re on the subject of Evaluate/Modify, you can now select more than whatever the limit used to be (80 characters?) and have your entire selection copied when you hit CTRL-F7. Good.

But while poking around in there, I found a new way to crash the IDE.  Try to evaluate a call that will open a form, and it locks up Evaluate/Modify.  Then hit CTRL-F2 to kill the debugger, and it brings the whole program down. Bad. (Not sure if this was in earlier versions, though. I’ve never run across it before.)

Oh, there’s a new regular expression library in the RTL.  Some people will probably find this a good thing.  I personally see it as Annoying. Delphi code is supposed to be easy to read.  That’s an explicit design goal going all the way back to Wirth.  But PCREs are anything but, and having it right there in the standard library will just encourage people to use them in code that I might end up having to debug some day.

In addition to Generics bugs getting cleaned up, the Generics.Defaults and Generics.Collections units got a bit of polish.  There were some minor tweaks to speed up various low-level comparison functions in Generics.Defaults.  Over in Generics.Collections, all the collections have gained a ToArray method, TStack<T> and TQueue<T> gained a Capacity, and there’s a new TThreadedQueue<T> class that looks a lot like the Blocking Collection that Primoz Gabrijelcic set up for OmniThreadLibrary, only without all the Omni stuff.  These new features look Good.

The Math unit has been given overloads for Single, Double and Extended precision versions of just about all its calculation routines, which is Good because there’s no more implicit conversions to introduce rounding errors.  However, I had this bite me when compiling some code at work.  Someone was passing an array of integers to Math.Sum, which worked before, but now the compiler gave an ambiguous overload error for that. Annoying, but not too hard to fix, since there’s a SumInt function right after Sum.  Not sure why the original author of this code didn’t use it in the first place.  Oh well…

In RTTI.pas, there’s a new class called TMethodImplementation.  You create it and give it data that describes the signature of a method, then pass it an anonymous method that takes an array of TValues and returns a TValue, and it creates a little thunk of machine code that builds a function with the correct signature that invokes your anonymous method.  Very cool, lots of potential… except that you can’t use it.  The constructor’s private, and there’s a public constructor that raises an exception, so you can’t get at it via TObject.Create.  It’s apparently for internal use only.  Annoying. I asked Allen Bauer about this, and he said that it’s because they weren’t sure they had the final form of the class worked out yet, and they didn’t want to make it publicly available yet in a form that they’d end up having to preserve and support forever afterwards.

There’s also a new class called TVirtualMethodInterceptor that is publicly available, and uses TMethodImplementation internally to allow you to replace virtual methods on a class.  I’m a bit curious as to what this is useful for, but apparently the team thought it was good for something, because a lot of work went into setting it up. Good?

Oh, and apparently certain aspects of the compiler have slowed down.  Most things will compile about the same speed or even a little faster, but for really large projects (millions of lines) with complex interdependencies between units, you’ll notice some slowdown, and it’ll apparently get worse the larger your project is.  I timed it at work, on a project of about 3.5 million lines of code.  It builds in about 2 minutes on D2010, closer to 3 minutes on XE.  Bad, but still a heck of a lot better than the C family could do.  And apparently it has something to do with making Generics work right, so I can tolerate that.  Hopefully they’ll find some way to regain some of that lost speed in updates, though.

Oh, and there are little {$IFDEF POSIX} and {$IFDEF MACOS} tags scattered throughout the RTL and VCL, even more than there were in Delphi 2010.  This is Good if you’re looking forward to OSX or Linux cross-platform development in the next release(s).  I haven’t seen any 64-bit ifdefs, but that could be because it doesn’t require much change at the Pascal level, the way a completely different OS platform does. (UPDATE: According to PhiS, there’s a lot of {$IFDEF CPUX64} tags in System.pas.  I was poking around the libraries with BeyondCompare last night but I didn’t bother to look in there because I knew that, with all the cross-platform stuff and all the ASM they’ve got in System.pas, the diff view would be a big, confusing mess no matter what.)

Well, it’s getting late and I haven’t had time to dig through too much of the new stuff yet, (and with a new 1000-page novel and a new video game, it might be a while,) but overall this is looking like a pretty good release.  Not a huge leap forward like the last two were, but a lot of polish and incremental improvements.  I think this is going to be a pretty good release overall.

“Why can’t I pass a TList<TMyDerivedObject> to a function that’s expecting a TList<TMyBaseObject>?  You can pass a TMyDerivedObject to a parameter expecting TMyBaseObject, so why doesn’t it work for lists?”

It really looks like it ought to be that simple, but unfortunately it’s not.  Trying to do this gets into a tricky issue in type theory known as covariance and contravariance, which is a formal way of describing the relationship between different types when one inherits from another.

It’s important to remember that object types don’t really exist at the binary level.  They’re an abstraction that makes it easier for us to work with them, but when you get down to it, all that’s there is a sequence of bytes.  As a strongly-typed language, it’s up to the Delphi compiler to make sure that, when you have a TMyDerivedObject, it doesn’t get replaced with a TMyIncompatibleObject that will cause things to crash or corrupt your data when you try to use it.  This is why you’re not allowed to pass descendant classes to a var parameter, for example:  because in the function using the var parameter, you’re allowed to replace the object with something else, and if the compiler can’t guarantee that the replacement will be of a compatible type, it prevents you from passing it in order to preserve type safety.

This is basically the same problem you get when dealing with generic lists.  Let’s say you have a TList<TMyDerivedObject> and you pass it to a function that expects a TList<TMyBaseObject>.  As long as all it does is reads the items in the list, you’re just fine.  But if this function calls .Add on the list and adds a TMyIncompatibleObject, (which also descends from TMyBaseObject, and so is perfectly legal in this context,) then you’ve violated type safety.  You have a list that’s supposed to only contain one type of object, and now there’s something incompatible inside.  And since this is done by calling a method on the list object and not by directly assigning one variable to another, the compiler can’t check to make sure you’re not doing something dangerous like this, so it forbids the entire concept in order to preserve type safety.

There’s a solution to this problem.  You can extend the language syntax a little so that the compiler does have a way to check this.  You have to mark the methods on the list so that the compiler knows that it’s safe for them to receive an object that descends from, or is an ancestor of, the specified generic type.  For example, you could mark TList<T>.Add with a hint that it’s OK to add descendants of the T type, but not ancestors.  Then the compiler uses this to determine more relaxed type safety rules that allow you to pass around different generic types without the danger of mixing incompatible types together.

The latest version of Prism supports this, but the Delphi team hasn’t implemented it yet.  I haven’t heard anything to indicate that they’re working on it for Delphi 2011 either.  Hopefully it they’ll find some way to implement it for Delphi 2012.

The tradeoff, though, seems to have been compiler stability.  Trying to do anything with Generics in D2009 before Update 3 came out was a nightmare, and even after, (and even in D2010,) there were still plenty of dark corners where you can end up with an Internal Compiler Error or linker error on something that, syntactically speaking at least, is perfectly cromulent Object Pascal.

I think I ran into the darkest corner of all this morning, or at least the darkest one that’s been found yet.  I found something that not only won’t compile, but will either destabilize or completely crash the IDE if you try to compile it.

I was trying to build a specialized tree class.  Trees are pretty familiar to anyone who’s taken a Data Structures class:  Each TreeNode contains a Value and pointers to two or more other TreeNodes.  There’s an excellent implementation of the standard binary tree concept in DeHL, for example.  This works really well if you’re trying to build a standard binary tree, but when you want a hierarchical tree, (like the way the VCL’s TTreeView organizes information,) the standard binary tree concept doesn’t work so well.

I came across a situation while building the TURBU editor where I had a list of objects with an ID property and a Parent property, where both are integers, and I needed to come up with a list of all objects whose Parent value was equal to the ID value of a given object.  In other words, all immediate children of a certain node.

Obtaining all descendants of a binary tree node is trivial if you understand recursion.  But that’s not what I needed; I needed all immediate children, but not their children.  So a different kind of tree is needed, one composed of TLists of nodes instead of binary subtrees of nodes.  So that’s what I wrote.  Each node contains a value, a pointer to the list it’s in, and a pointer to the list containing its children, and each list is a list of nodes, plus a pointer to its parent node.  It ended up looking like this:

unit hierarchy_tree;

interface
uses
   SysUtils, generics.collections;

type
   THierarchyTreeList<T: class> = class;

   THierarchyTreeNode<T: class> = class
   private type

      TEnumerator = class(TEnumerator<T>)
      private
         FTopNode: THierarchyTreeNode<T>;
         FIndex: integer;
         FNext: TEnumerator;
         FTopRead: boolean;
      protected
         function DoGetCurrent: T; override;
         function DoMoveNext: Boolean; override;
      public
         constructor Create(value: THierarchyTreeNode<T>);
         function GetCurrent: T;
         function MoveNext: boolean;
         property Current: T read GetCurrent;
      end;

      TNodeList = THierarchyTreeList<THierarchyTreeNode<T>>;

   private
      FData: T;
      FRight: TNodeList;
      FList: TNodeList;
      function GetParent: THierarchyTreeNode<T>;
      function GetLevel: integer;
   public
      constructor Create(value: T);
      destructor Destroy; override;
      procedure Add(node: THierarchyTreeNode<T>); overload;
      procedure Add(value: T); overload;
      function GetEnumerator: TEnumerator;

      property List: TNodeList read FList;
      property Right: TNodeList read FRight;
      property Parent: THierarchyTreeNode<T> read GetParent;
      property Level: integer read GetLevel;
      property Data: T read FData write FData;
   end;

   THierarchyTreeList<T: class> = class(TObjectList<THierarchyTreeNode<T>>)
   private
      FParent: THierarchyTreeNode<T>;
      FLevel: integer;
      procedure SetParent(Value: THierarchyTreeNode<T>);
   public
      constructor Create(parent: THierarchyTreeNode<T>);
      function Add(value: THierarchyTreeNode<T>): integer;
      property Parent: THierarchyTreeNode<T> read FParent write SetParent;
      property Level: integer read FLevel;
   end;

implementation

{ No implementation provided.  Compiler will break before reaching this
point anyway. }

end.

You can try to compile this if you want, but make sure to save any work before you try.  Turns out this will break the compiler.  The compiler will try to process this, get stuck for about 30 seconds, all the while sucking up memory like there’s no tomorrow, until it hits 1.5 GB according to Task Manager, and then break.  It may crash, or it may simply become unstable.  If you’re really lucky, you’ll get an Out Of Memory error so at least you have some idea what’s going on.

After sharing this problem with a few other coders, I’ve got some idea what’s going on.  The node uses the list in its definition, and the uses the node as its generic parameter.  Apparently the compiler is trying to resolve one of these generics immediately, instead of waiting for instantiaion when a value of T can be provided, and getting stuck in an infinite loop, even though the definition is not infinitely recursive.

I’ve submitted a bug report about this to QC . Thanks to Moritz Beutel and Stephen Kamradt for the insights as to what was going on!