C# VS Delphi Garbage Collection

Question

1.00/5 (1 vote)

See more:

After having been primary a Winforms C# developer, I am now being forced to move to Delphi 10. And although, so far, a lot of the differences seem relatively minor, the garbage collection seems VERY different.

Can anyone give me some advice with how resources freeing works in Delphi? Baring in mind that I have a .net background. The last thing I want to be doing in my new job is causing major memory leaks everywhere.

Posted 31-Oct-15 1:26am

TheRedEye

Add a Solution

1 solution

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2015-10-31T15:56:00

Solution 1

There is no garbage collection in Delphi, not at all. You need to allocate memory in heap and take care of deallocation yourself. You got some assistance in this with certain types, such as Delphi strings and interfaces.

To learn how to do it all with Delphi, you have to… learn Delphi, first of all, all the language and its semantic, as well as the general principles of heap, pointers and memory management in general. You can get some idea if you start, say, with this short article: http://delphi.about.com/od/oopindelphi/a/memoryleak.htm[^].

See also: http://delphi.about.com/od/toppicks/tp/aatpmemleak.htm[^].

I personally used MemCheck, it's very useful.

—SA

Posted 31-Oct-15 15:56pm

Sergey Alexandrovich Kryukov

v2

Comments

TheRedEye 3-Nov-15 8:47am

Thanks for your reply, the articles helped. In the following code does the FreeAndNil(ListOfThings) free all necessary objects?

function GetList(): TObjectList<tsomeobject>;
var
MyItems: TObjectList<tsomeobject>;
AnItem: TSomeObject;
i: integer;
begin
MyItems := TObjectList<tsomeobject>.Create();
for I := 0 to 9 do
begin
AnItem := TSomeObject.Create();
MyItems.Add(AnItem); // MyItems becomes owner of each AnItem.
end;
Result := MyItems;
end;

procedure DoSomething();
var
ListOfThings: TObjectList<tsomeobject>;
begin
ListOfThings := GetList();
// ....
FreeAndNil(ListOfThings); // will this free ListOfThings, MyItems and all 10 of AnItem objects?
end;

Sergey Alexandrovich Kryukov 3-Nov-15 8:58am

All right; as soon as you create an object of a class, you actually get a pointer to an object placed in the heap. So, you have to release each and every one of them eventually. Normally, it is done via the chain of destructors; each object is responsible for descruction of its parents.
—SA

TheRedEye 4-Nov-15 7:17am

So in the above example, please correct me I'm wrong with any of this.

ListOfThings and MyItems are pointers to the same object in the heap. So calling FreeAndNil(ListOfThings) will also free MyItems. And MyItems is the parent and owner of every instance of AnItem. So when MyItems is freed, then all the instances of AnItem are also freed. Is this correct?

Sergey Alexandrovich Kryukov 4-Nov-15 15:15pm

Strictly speaking, free is related to the object in heap, not pointer to it. Therefore, if you have to pointers pointing to the same object, and you free the object, the pointer keeps pointing to a garbage in memory and should not be used. I hope you understand it and will just take into account. That's why there is a reference counting technique, but it only applied to interface pointers.

One of the usual technique is UML-style classification of pointer-based relationships into "compositions" and "associations". In managed systems, this classification is blurred, but can be used, or not, due to the fact that GC is based on reachability. Compositions form an object tree (not general graph, only a tree) where all the parents take sole responsibility over the lifetime of all their children. Therefore, the pointers making composition tree can always be maintained valid. For example, some parent note can be a list of pointers to children. When you remove a child, you first free it, and then remove the pointer from list. This is should be the atomic operation which never leaves invalid pointers behind. And the destructor of this child takes care of its children, and so on, recursively. As this is just a tree, recursion always ends. All other pointers (making "associations") should not be considered reliable in this respect. The code should not try to free any objects through such pointer.

I hope you can grasp the idea.

And yes, use something like MemCheck.

—SA

C# VS Delphi Garbage Collection

1 solution

Solution 1

Add your solution here

Preview 0

C# VS Delphi Garbage Collection

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us