Delphi Language Guide Delphi for Microsoft Win32 Delphi for the Microsoft. Net framework

Note:
A constructor can initialize fields from its own class, prior to calling the inherited constructor.
Finalization
Every class in the .NET Framework (including VCL.NET classes) inherits a method called Finalize. The garbage
collector calls the Finalize method when the memory for the object is about to be freed. Since the method is called
by the garbage collector, you have no control over when it is called. The asynchronous nature of finalization is a
problem for objects that open resources such as file handles and database connections, because the Finalize method
might not be called for some time, leaving these connections open.
To add a finalizer to a class, override the 
strict protected
Finalize procedure that is inherited from TObject.
The .NET platform places limits on what you can do in a finalizer, because it is called when the garbage collector is
cleaning up objects. The finalizer may execute in a different thread than the thread the object was was created in.
A finalizer cannot allocate new memory, and cannot make calls outside of itself. If your class has references to other
objects, a finalizer can refer to them (that is, their memory is guaranteed not to have been freed yet), but be aware
that their state is undefined, as you do not know whether they have been finalized yet.
When a class has a finalizer, the CLR must add newly instantiated objects of the class to the finalization list. Further,
objects with finalizers tend to persist in memory longer, as they are not freed when the garbage collector first
determines that they are no longer actively referenced. If the object has references to other objects, those objects
are also not freed right away (even if they don’t have finalizers themselves), but must also persist in memory until
the original object is finalized. Therefore, finalizers do impart a fair amount of overhead in terms of memory
consumption and execution performance, so they should be used judiciously.
It is a good practice to restrict finalizers to small objects that represent unmanaged resources. Classes that use
these resources can then hold a reference to the small object with the finalizer. In this way, big classes, and classes
that reference many other classes, do not hoard memory because of a finalizer.
Another good practice is to suppress finalizers when a particular resource has already been released in a destructor.
After freeing the resources, you can call SuppressFinalize, which causes the CLR to remove the object from the
finalization list. Be careful not to call SuppressFinalize with a nil reference, as that causes a runtime exception.
216

---