12

I would like to know WHY do we use "Finalization" if we want to destroy something when closing the application? doesn't closing the application frees all objects directly without calling .Free?

Thanks.

user1512094
  • 611
  • 2
  • 10
  • 23
  • 2
    Avoid using Initialization / Finalization sections in units. They come from ancient Turbo Pascal. Create, Init and Free objects explicitly when you need it. – Marcodor Aug 01 '12 at 10:53
  • 3
    @Marcodor If you really have a truly global object like a singleton then unit initialization/finalization is appropriate – David Heffernan Aug 01 '12 at 12:03
  • 3
    Initialization runs before any forms are created - I find this an ideal place to create resources upon which multiple forms will depend and, even more importantly, resources that must outlive all form instances and, indeed outlive the whole Delphi application. Finalization sections are still occasionally useful too. – Martin James Aug 01 '12 at 14:46
  • 1
    @MartinJames initialization are however 'always on', no way to suppress them except by messy compiler conditions or global variables. I prefer more control and initialize everything a) when needed (using singletons) and also b) at startup before creating any user interface objects. IMHO they are getting more a legacy language element. Static class initialization in Java is an example for object oriented initialization, it runs when the class is used the first time - for example by invoking one of its static (class) methods. – mjn Aug 01 '12 at 14:58
  • @DavidHeffernan Although I disagree, I do not want to get into a polemic here. There is a lot of programming languages, especially with a modern design, that do not have initialization/finalization. And they are just fine. An alternative you can use class/object methods. They just can cause a lot of problems: http://stackoverflow.com/questions/4618650/delphi-unit-initialization-not-always-called http://stackoverflow.com/questions/2301355/delphi-and-finalization-in-a-unit http://stackoverflow.com/questions/4403002/why-is-there-no-intialization-keyword-in-c-as-there-is-in-delphi – Marcodor Aug 01 '12 at 16:15
  • 2
    @Marcodor The features of other programming languages, whilst interesting, don't change the way you program in Delphi. If you want something to run as the module unloads, there are not many alternatives to the finalization section. – David Heffernan Aug 01 '12 at 16:18
  • @DavidHeffernan now we have class destructors that covers most uses of finalyzation. Though not all probably. – Arioch 'The Aug 02 '12 at 08:46
  • 1
    @Arioch'The Class destructors are simply syntactical sugar for finalization code. They are invoked using exactly the same mechanism. – David Heffernan Aug 02 '12 at 08:47
  • No, they are more than merely sugar. Don't forget about Smart Linker – Arioch 'The Aug 02 '12 at 08:48

2 Answers2

19

Doesn't closing the application frees all objects directly without calling Free?

No. Delphi class instances are not garbage collected and so they need to be manually destroyed.

However, if you are talking about an executable process, then it can be perfectly acceptable not to dispose of certain objects since the operating system will re-claim all resources owned by a process when that process terminates. So even though Delphi destructors don't run, the OS tidies everything up when a process terminates. It is not possible for a process to leak any system resources once it has terminated.

Note that if the unit is included in a DLL or a package then failure to destroy all objects at finalization time will lead to memory leaks, if that DLL is repeatedly loaded and unloaded into a single process.

If you know that your code only ever runs in an executable, then feel at liberty not to Free objects at finalization time. Be aware that if you are using a memory leak detection tool then doing so will result in your intentionally leaked object being treated as a memory leak. Deal with that by calling RegisterExpectedMemoryLeak.

One final point to make is that an object's destructor sometimes does more than free memory. Sometimes it can save values to a settings file, or the registry, for example. Naturally you would not want to omit running the destructor for such an object.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
5

Adding to the final point of David Hefferman's answer: There are other resources that might need to be freed correctly, like file handlers that generate a checksum or some hardware connected to the PC that must be put in a specific state (e.g. a laser to be turned off, which is what I am currently working with).

dummzeuch
  • 10,975
  • 4
  • 51
  • 158