MusicWind has solemnly declared in June 2004: The following is purely a nonsense, ridiculous! Related content published in a certain issue of 9CBS programmer magazine, and it is unfortunately unfortunately. Here to the reader!
Explore: How to determine if the object pointer in Delphi is available
Author: Musicwind?
Creation time: 2001-08-07
Recently, I saw some netizens asked: How to determine if an object pointer is available? That is, how do I determine if an object pointer points to a truly available object instance? In fact, this should not be a problem. Because he should be able to control your own programs, you should not access an invalid pointer because all object instances are created and destroyed under him. And even if there is no direct approach to determine if the object pointer is available, you can do this by other indirect paths (such as using some identity, etc.) (for example, after we destroy an object instance, we will specify the object pointer For nil). But if we leave the two points not talking about, let's study in Delphi, have there any way to judge whether an object pointer is available, how is it?
In Object Pascal, a class can have two types of methods, a class method (Object method), and the other is a class method (Class Method). The so-called object method refers to the definition of the method being aimed for the object (or called instance), so calling the method requires an object (or called an instance), such as the destructor DESTROY is an object method (in fact we often Most methods used are object methods). The method, refers to the method's definition is based on a class of objects, so calling the method does not require a specific object instance, such as the class constructor CREATE. This is some inspiring for us. Determine if an object pointer is available, it seems to be completed by the following steps. First, we can determine if the object pointer is nil. If so, then you will tell, it is undoubtedly unavailable; if no, then the object method of the object is tried to see if there is an exception such as invalid memory access, by This is to determine if the object is available. Use the following code to verify our ideas:
VAR
Obj: TOBJECT;
Begin
Obj: = TOBJECT.CREATE; // 1. Create an object
Obj.free; // 2. Release the object that has just been created, at which time the memory is recycled
IF obj = nil dam/3. Judging whether the pointer is empty, (this step is often unsuccessful, because the object
// is released, Delphi will not automatically set the object to the needle)
ShowMessage ('object pointer is not available.')
Else
Begin
Try
If Obj.clasStype = TOBJECT THEN / / 4. A method of calling Tobject
ShowMessage ('object type is TOBJECT');
Except
ShowMessage ('object pointer is not available.')
END;
END;
END;
Execute the above code, we find that Obj.classType is still available even if Obj.Free has already performed. This shows that not all object methods must rely on an object instance to access. The reason is because this object method does not need to access the memory applied by an object instance. In this sense, the TOBJECT.CLASSTYPE method is not like a real object method, and there are quite a taste of some ways. Execute the above code, we can also find that an object executes the Free method, just release it all the memory released in creation, but does not affect the value of the object pointer itself. The object pointer is still pointing to the original memory address. At the same time, due to certain object methods (such as classType), even if the object has been released, the call result of the object method is still correct.
In summary, we can draw a conclusion, that is, whether an object pointer can be judged to be available, to see if the object pointer belongs, provides access to the object instance memory - this path can be Method, it can also be attribute. So, what is the situation in each class now?
TOBJECT, this class is all the ancestors of all classes, and there is no way to make a judgment.
TPERSISTENT, is derived from TOBJECT to create an object instance, there is no need to apply for additional memory, so there is no way to judge.
Tcomponent, is derived from TPERSISTEN, adding many properties that need to be applied for an additional memory when creating an object instance, so it is determined by theoretically. code show as below:
Function Componentexists (ACOMPONENT: TComponent): boolean;
Begin
Try
Acomponent.hasparent; // Note: This sentence can also be "Acomponent.tag;"
/ / Or "Acomponent.name"
RESULT: = true;
Except
Result: = FALSE;
END;
END;
By calling ComponEntexists, we can learn whether the Tcomponent type object pointer is available, regardless of whether the object pointer has been released, whether it is set to NIL.
Other classes, such as TControl, TwinControl, or TButton, etc., as long as it is derived from Tcomponent, the Judgment method of Tcomponent is still applicable.
There are other user-defined classes, if they are derived from classes that cannot be judged (such as TOBJECT and TPERSISTENT), but there is no need to apply for memory at the time of instantiation, then there is no way to judge; it can be. According to an example:
Suppose we have a TPERSON class, defined as follows:
TPERSON = Class (TOBJECT)
Private
FSEX: TSEX; // Tsex is the gender of enumeration type;
Ffirstname: string;
Flastname: String;
// ...
Public
Property Sex: Tsex Read FSEX WRITE FSEX;
Property Firstname: String Read ffirstname Write FfirstName;
Property Lastname: String Read Flastname Write FlastName
// ...
END;
Then, for the TPERSON type pointer Person, you can use the following code to determine if the pointer is available: Try
Person.sex;
// or person.firstname;
// or Person.lastname;
Result: = true; / / pointer available
Except
Result: = false; // Pointer is not available
END;
It is only a technical possibility that we discussed above. What I want to emphasize is that even if there is a good way to do it, I don't encourage it to do this. Because, a logical tight program should be able to prevent access to an invalid pointer.
More articles
Culture
