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

Everything in c# is garbage collected, so you do not need to free them manually.

But there are significant differences. Delphi interfaces are reference counted, c# interfaces are garbage collected. C# supports multiple interface inheritance.

Answer 2

Yes, to a programmer they look the same. Use And Forget.

Internally they work different, in .NET an interface is (just another) reference that is sweeped by the Garbage collector.

In Delphi interfaces are a special kind of reference that are reference-counted (a different Meory management technique).

The main .NET/Delphi difference is that in .NET all references (interface, object and array) are garbage Collected.

Answer 3

I don't think it is freed when out of scope but when the garbage collection happens (when they are not used anymore)

Answer 4

Memory management is handled by the CLR. Garbage collection is an intrinsic service in the CLR.

You do not need to null out variables or fields in order to have the object collected by garbage collection.

You do not need to implement or use IDisposable to clean up memory. The Dispose method does nothing to free managed objects in memory. The Dispose method is should be used to free up "unmanaged" resources including database connections, bitmaps, or any unmanaged structures you may be holding onto.

If you are talking about interfaces as in visual components (Forms, dialogs, etc), this gets a little bit more confusing. In WinForms, I believe that when an interface (visual) is no longer visible, it will be cleaned up and garbage collected. The form will be recreated again when it is needed. In WPF, Windows and Pages are not immediately destroyed. They are cached for the lifetime of the application unless they are specifically cleaned up by the application developer. This improves performance with WPF applications but places an additional burden of having to worry about resources in your application.

Garbage collection is a completely separate topic. The actual freeing of managed objects from physical memory occurs in here and is completely up to the Garbage Collection service and you should not normally have to worry about how this works.

Cheers

Answer 5

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.