destroy and data erasing

[savage]

I've edited Robert's post to reflect the override; change, so that any newbies looking at the code can see what is the correct thing to do.

[marmin]

Anything created or allocated must be manually freed; objects, arrays, arrays of objects, and records (especially if they contain the previous) for good form.
In your code you should call free, but in designing an object you should override destroy. Any further questions?

No, I understand, but I've a huge amount of dyn. arrays and lists, and I figured it would be very nice if the compiler could 'free' them automatically. In theory that could work.

[Robert Kosek]

Thanks guys, I forgot that one little tag.

In theory sure, and this is what things like C# and Java do: garbage collection. Though, sometimes you want to leave that memory allocated, and so have to work around the language. Pascal at least gives you the option, though it requires you to do most your own cleanup. Though I must admit pascal even makes that easy.

[savage]

No, I understand, but I've a huge amount of dyn. arrays and lists, and I figured it would be very nice if the compiler could 'free' them automatically. In theory that could work.

But the question is, when should it free then automatically? If you have created the object within your code, when does the compiler know, except when the application is shutting down? Any other scenario would require a garbage collector.

Garbage collectors check and decide when something goes out of scope, but that is where some of the speed is lost because a background thread is always looking for unused objects.

[marmin]

Well, everything that is created inside the constructor, is freed inside the destructor. If I call x.Destroy .The compiler has made a list (when calling x.Create) what dyn. arrays or pointers were created, and erases these. Of course, this problem arises because i'm purist and like to torture me with home-made linked lists. But.. compiler can do it. It should keep track what arrays etc. are made inside create and free it when called destructor.

[savage]

What happens in the case where your create an object inside one class, but it is used in some other class? For example a factory pattern only tends to create objects, while other classes may use those objects. Will the compiler know then when it should be freed?

[marmin]

Afaik when an object is destroyed it doesn't exist anymore so it can't be used.. if there is a reference to that object in some other object then that object should take care not to use the 1st object.. this is not an oop issue but simply teh compiler has an extra job to do..

[jdarling]

Marmin thats called interfaced objects, and to answer savages point thats why we have messages and listener queues . FPC and Delphi are not Garbage collection languages, due to Chrome you can't say that Pascal isn't a GC'd language in general .

Some factory objects to maintain the children that they produce. For example JumpStart uses a factory to create and manage all objects utilized within the game. Each object has a Lua reference that says if Lua is utilizing the object as well. When the Lua Garbage Collector is called the objects are only freed if they are not in use some place else. When they fall out of use completely the factory cleans up (effectively producing a true garbage collection system within FPC).

Of course, the fun part is deciding when an object is in use .

[Setharian]

Anything created or allocated must be manually freed; objects, arrays, arrays of objects, and records (especially if they contain the previous) for good form.

destructor TThingy.Destroy;
begin
  setlength(fArray,0);
  inherited Destroy;
end;

Don't override MyObject.Free ever. Only override the destroy destructor and Delphi/FPC/Lazarus will do the rest. The point is, just override the descendant function and then call the parent one. Free isn't a function intended to be overridden, and was written to do a few things and then call the destroy event.

not exactly true....everything allocated manually that is using GetMem/AllocMem/New or other forms of manual memory allocation (OS API)....dynamic arrays, interfaces, strings are reference counted and thus you do not need to free them explicitly....if you create dynamic arrays of pointers or classes (which are actually pointers) then you have to deallocate elements explicitly (if you want to), but the array is automaticly deleted once its reference count reaches zero.....so the line "SetLength(fArray, 0)" is not needed...as a side note, .Free is not virtual so you cannot override it....

[jdarling]

Define overriding it. You can certainly reintroduce free as a procedure and it will be called instead of the default one. You can then do an inherited free within your reintroduced version that will call the original. So saying that you can't override it is incorrect . Granted you can't use the override keyword to achieve it, but the end result is the same.