TURBU Tech

Quick, what’s wrong with this code?

procedure ContrivedExample;
var
   factorial: TFunc;
begin
   factorial :=
      function(input: Integer): integer
      begin
         if (input = 0) or (input = 1) then
            result := input
         else result := input * (factorial(input - 1));
      end;

   writeln(factorial(5));
end;

Or how about this one, which doesn’t use recursion, and is based on something I noticed when using the list comparison algorithm to solve a problem at work?

procedure SomewhatLessContrivedExample(list1, list2: TList);
var
   newItem, editItem, deleteItem: TProc;
begin
   newItem :=
      procedure(value: TMyObject)
      begin
         fMainList.Add(value);
      end;

   editItem :=
      procedure(value: TMyObject)
      begin
         if value.CheckSomeFlag = true then
            newItem(value)
         else fMainList[value.id].Update(value);
      end;

   deleteItem :=
      procedure(value: TMyObject)
      begin
         fMainList.Delete(value);
      end;

   listCompare(list1, list2, editItem, newItem, deleteItem);
end;

If you were paying close attention in my first two posts about how anonymous methods are implemented, you might realize that these anonymous method references are interface references to a TInterfacedObject descendant, and that by having the closure capture one, the object now holds a reference to itself.  Which means that when you actually run the code, you could end up with FastMM4 reporting something like this:

An unexpected memory leak has occurred. The unexpected small block leaks are:
21 – 28 bytes: ContrivedExample$ActRec x 1

Oops!  That’s not good, especially if you call ContrivedExample in a main loop somewhere and end up leaking hundreds of thousands of them.  This is too bad, since there are all sorts of interesting things you could do by using anonymous methods recursively.  And since anonymous methods don’t have a name, they can’t invoke themselves recursively without capturing the reference variable.

There’s probably no way for the compiler to prevent this in the general case, but it could be solved easily enough for examples that fit the pattern described in my examples:  When an anonymous method reference variable is only assigned once in an enclosing procedure, and that one point is where the method is defined within the procedure (i.e. it’s not passed in as a parameter or already assigned at global or object scope), then the compiler can be certain that the Self pointer for the underlying object is the same as the one it’s currently executing on, and transform it behind the scenes from an interface reference to a normal method call.

Can anyone else think of possible ways to fix this?