Delphi object Creation (create) and release (Free/destory)

Must be free after create.

Simple examples
Procedure A;
var x:tx;
Begin
X:=tx.create;
Do someting;
X.free//If I am not free here, this end is not the equivalent of C in the automatic release of the}.
In other words, this free is superfluous here. Is that right.
End

But for reliability and readability, this free is best not to save.
And it's going to be loaded with try...finally...end.
This ensures that resources can be released even if you have an exception in the process.

But for reliability and readability, this free is best not to save. And it's going to be loaded with try...finally...end. This ensures that resources can be released even if you have an exception in the process.

But for reliability and readability, this free is best not to save. And it's going to be loaded with try...finally...end. This ensures that resources can be released even if you have an exception in the process.

To you, be sure to free, otherwise there will be memory leak.
But if the shape is x: = TX. Create (application) In this way, you can not free, then application is free, application will be for you.

Delphi object Creation (create) and release (Free/destory)

1, create parameter is: nil/self/application difference, it is best to see the difference between the actual effect

For example: my: = Tmy.create (X);

Where X will become the Owner property of the control's my

There may be more than one control that treats X as Owner.

When X is released, it releases all controls that treat it as Owner at the same time.

Such as:

BTN1: = Tbutton.create (PANEL1);

BTN2: = Tbutton.create (PANEL1);

Btn3: = Tbutton.create (PANEL1);

When Panel1.free, BTN1, BTN2 and Btn3 are both released.

If btn1: = Tbutton.create (Self); {For example, Self is a form}

The BTN1 will also be released when the form is released.

BTN1: = tbutton.create (application);

BTN1 is also released when the program is destroyed.

This is basically no different for a single form program, but it's different if it's a multiple form.

If btn1: = Tbutton.create (nil);

Then BTN1 had to be responsible for manual release (BTN1. Free).

You may ask: if Btn1 's form has been destroyed, will BTN1 still exist?

A: If application is still in btn1, it will not disappear (in the case of Create (nil)).

In general, when application is gone, the system releases the controls it contains.

But it is not a good habit to wait for the system to do this, because there are exceptions (usually in the course of a process):

An object may have a longer memory allocation than the object itself.

2, Delphi Cancellation method has two: Destroy and free.

Delphi recommends using free because it is more secure than destroy, and calling free generates more efficient code.

You can release the exhausted employee object with the following statement:

Employee.free;

As with the Create method, the free method is also inherited from the TObject Temployee. Put your logoff in the finally part of the TryFinally program module,

It is a good habit of programming to put the object's program code in the try part. This way, even if your program code has an exception event when you use the object,

It also ensures that the memory you allocate for this object is freed.

The difference is that Destroy will directly release the object,

And the free will actually check whether the object exists, if the object exists, or if the object is not nil, it will invoke destroy.

Therefore, it is safer to use free as much as possible in your program to release objects.

(note, however, that free does not automatically set the object as nil, so after you call free, it's best to manually set the object to nil.) ）

The TObject class has a fictitious destroy function and a non-virtual free function. The free function is called destroy.

Therefore, when we call on any object (which is a subclass object of TObject). Free (), then the Tobject.free () is executed;

It will invoke the destructor of the object we are using destroy ();. This ensures that any type of object can be correctly refactored.