Whats the difference in terms of memory usage (clean up, etc) of Delphi Interface and C# interfaces

Question

I am a Delphi programmer and trying to get some stuff done with C# here. Does interfaces in C# works in the same way as in Delphi - you don't need to worry in freeing it as it is freed when its out of scope.

Answer 1

The key difference between Delphi and .NET in this area, relating specifically to interfaces, is the non-deterministic nature of the clean-up.

In Delphi all interface usage follows the COM model. That is, it is reference counted. If the class implements a reference counted lifetime management model, then when the reference count drops to zero the object instance is destroyed AT THAT POINT.

NOTE: Lifetime management is a function of the class implementation. To see this most clearly, a look at the implementation of IUnknown.Release in TInterfacedObject:

function TInterfacedObject._Release: Integer;
begin
  Result := InterlockedDecrement(FRefCount);
  if Result = 0 then
    Destroy;
end;

If the implementation of Release did not call Destroy, then the object would NOT be destroyed when the reference count drops to zero and would still have to be explicitly Free'd through some object reference to the object. This can be used in Delphi to create objects which implement interfaces but which are not subject to automatic, reference counted lifetime management (though you cannot avoid the reference counting code injected by the compiler, i.e. calls to AddRef and Release).

In .NET first of all there is no reference counting per se. The Garbage Collector works in a far more sophisticated fashion, the details of which are not directly relevant to this discussion.

The key difference is that when an object is no longer being used (however that is determined beyond a simple reference count) that is NOT the point at which it is destroyed in .NET.

In fact, it is theoretically possible that unused objects would accumulate in your application until a much, much later point in your process lifetime - especially in compute intensive applications with few idle cycles. In .NET you simply cannot be sure precisely when those unused objects will eventually be free'd.

Some would argue that this is A Good Thing, though it confuses the usual practice of cleaning up resources that are locked or owned by objects when those objects are destroyed, since you typically need to release those locked/owned resources more urgently than is afforded by waiting around for the Garbage Collector. This is where IDisposable comes in in .NET, the details of which are again not directly relevant can may be researched further at your leisure.