Do you call free in .NET DELPHI?
Garbage recycling this, garbage recycling that. Delphi developers are used to releasing the object ... Now .NET garbage collector replaces the release of the object, the problem is: When are you needed or must be released? Should you "release" object? This article provides an understanding!
This is the third article of the series, the sputum is annoyed.
ANOBJECT.FREE
I assume that you have written a lot of code based on WIN32 development solution. Running and release the object is a very common thing ... in the Win32 field, any object instance is running, if it is not used, it should be called free to destroy, so that it can be completely destroyed and released. RAM. In other words, we often use the same code segment as the following:
Anobject: = TanObject.create (nil);
Try
// ...... Code related to the object
Finally
ANOBJECT.FREE;
END;
When you run anobject, call the "free" mode to ensure that the memory occupied by the Anobject is released.
"Now" (in the .NET field) they tell you: "You no longer need to release your object!", Everyone is talking about garbage collection (GC).
I am confused (I believe you also)! Should I call free? What is the garbage collector in .NET? Will I turn off after a file or database is used? GDI resource (do you want to release)?
Let us study!
Garbage collector
In the .NET frame, a new function is to automatically recover in garbage. Garbage recycling This term can be defined as: Managing the assignment and release of memory in the application. In other words, .NET Garbage Collection (GC) completely liberates you from tracking memory usage and initiating the developer who releases memory.
The GC's engine determines the best time to perform a garbage collection. When the garbage collector performs a collection, it checks for objects in the managed heap that are no longer being used by the application and performs the necessary operations (automatically releases the memory allocated) To Reclaim Their Memory. What this Means, IS That in Delphi for .NET, You CAN * SAFELY * CREATE AN Object without "Freeing" IT.
Every Application Uses Resources of One Sort or Another: Memory Buffers, Files, Database Connections, Network Resources, And So ON.
GC is not "all mighty" - if you are using "external" resources, like database connections or network resources, you are still responsible for freeing "unmanaged" (or external) resources The framework can track when the unmanaged resource needs to be. terminated, but it does not have information on how to terminate the resource and free up the memory. In order to force the developer to free its resources, any class that operates on "unmanaged" resources must implement the Dispose (made it public) method of the IDisposable interface. In general, your implementation of the Dispose method should release all the resources that an object owns (with a call to "inherited Dispose"). Finalize, IDisposable.Dispose, Free, Destroy?
Every class in the .NET Framework inherits a method called Finalize. The bad news is that the GC calls the Finalize method (and therefore if overridden it should be protected) 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 good news is that in Delphi for .NET, all objects implicitly implement IDisposable and redirect calls to Dispose to the Destroy destructor. This means that you do not need to implement Dispose yourself ... you can safely continue freeing resources (for objects / Classes You Develop) in The Object's Destructor "Destroy" Method.
SHOULD you call anobject.free?
Recall that, in Win32, calling "Free" automatically calls the destructor if the object reference is not nil. In .Net, on the on the hand, a call to Free is (as stated above) redirected to Dispose which in turn calls your DESTRUctor.
What this means is what when you call free in .net, you actually call idisposable.dispose.this is the delphi for .NET VERSION OF THE "Free" Method (from source code):
Procedure TOBJECTHELPER.FREE;
Begin
IF (Self <> nil) and (self is idisposable) THEN
Begin
IF assigned (vclfreenotify) THEN
VCLFreenotify (Self);
Self as idisposable .dispose;
END;
END;
What this tells us, is that to free "unmanaged" (external) resources, you can safely continue using "Free" inside try-finally blocks (since you do not * generally * know whether an object you create uses "unmanaged" resources) .
Conclusion: Delphi code you write remains the same, but the compiler implementation changes significantly You do not need to be frightened of calling "Free", nor should you change all your Win32 projects you are about to pre-compile using VCL.Net.!
Note: Be Sure To Read The "Memory Management Issues on The .NET Platform" Topic in the delphi for .NET HELP System.
