How to effectively use interfaces for memory management in Delphi

Question

I'm fairly new to Delphi and have been doing all my memory management manually, but have heard references to Delphi being able to use interfaces to do reference counting and providing some memory management that way. I want to get started with that, but have a few questions.

1. Just generally, how do I use it. Create the interface and the class implementing it. Then anytime I need that object, have the variable actually be of the Interface type, but instantiate the object and presto? No nee to think about freeing it? No more try-finallys?

2. It seems very cumbersome to create a bunch of interfaces for classes that really don't need them. Any tips on auto generating those? How do I best organize that? Interface and class in the same file?

3. What are common pitfalls that might cause me grief? Ex: Does casting the interfaced object to the an object of its class break my reference counting? Or are there any non-obvious ways Delphi would create reference loops? (meaning besides A uses B uses C uses A)

If there are tutorials that cover any of this, that would be great, but I didn't come up with anything in my searches. Thanks.

Answer 1

I am currently working with a very large project that takes advantage of the "side affect" of interface reference counting for the purpose of memory management.

My own personal conclusion is that you end up with a lot of code that is overly complex for no better reason than, "I don't have to worry about calling free"

I would strongly advise against this course of action for some very basic reasons:

1) You are using a side affect that exists for the purpose of COM compatibility.

2) You are making your object footprint and efficiency heavier. Interfaces are pointers to lists of pointers.. or something along those lines.

3) Like you stated... you now have to make piles of interfaces for the sole purpose of avoiding freeing memory yourself... this causes more trouble than it's worth in my opinion.

4) Most common bug that will be a HUGE pain to debug will become when an object gets freed, before it's reference. We have special code in our own reference counting to try and test for this problem before software goes out the door.

Now to answer your questions.

1) Given TFoo and interface IFoo you can have a method like the following

function GetFoo: IFoo;
begin
  Result := (TFoo.Create as IFoo);
end;

...and presto, you don't need the finally to free it.

2) Yes like I said, you think it's a great idea, but it turns into a huge pain in the bupkis

3) 2 problems.

A) you have Object1.Interface2 and Object2.Interface1... these objects will never be freed due to the circular reference

B) Freeing the object before all the references are released, I cannot stress how dificult these bugs are to track down...

Answer 2

The most common complaint leading to the desire for "automatic garbage collection" in Delphi is the way that even short-lived temporary objects have to be disposed of manually and that you have to write a fair amount of "boiler-plate" code to ensure that this takes place when exceptions occur.

For example, creating a TStringList for some temporary sorting or other algorithmic purpose within a procedure:

procedure SomeStringsOperation(const aStrings: TStrings);
var
  list: TStringList;
begin
  list := TStringList.Create;
  try
      :
     // do some work with "list"
      :
  finally
    list.Free;
  end;
end;

As you mentioned, objects that implement the COM protocol of reference counted lifetime management avoid this by cleaning themselves up when all references to them have been released.

But since TStringList isn't a COM object, you cannot enjoy the convenience this offers.

Fortunately there is a way to use COM reference counting to take care of these things without have to create all new, COM versions of the classes you wish to use. You don't even need to switch to an entirely COM based model.

I created a very simple utility class to allow me to "wrap" ANY object inside a lightweight COM container specifically for the purpose of getting this automatic cleanup behaiour. Using this technique you can replace the above example with:

procedure SomeStringsOperation(const aStrings: TStrings);
var
  list: TStringList;
begin
  AutoFree(@list);

  list := TStringList.Create;

    :
  // do some work with "list"
    :
end;

The AutoFree() function call creates an "anonymous" interfaced object that is Release()'d in the exit code generated by the compiler for the procedure. This autofree object is passed a pointer to the variable that references the object you wish to be free'd. Among other things this allows us to use the AutoFree() function as a pseudo-"declaration", placing any and ALL AutoFree() calls at the top of the method, as close as possible to the variable declarations that they reference, before we have even created any objects.

Full details of the implementation, including source code and further examples, are on my blog in this post.