Please give me some food for your mind about DELPHI pointers!
No, of course I read the mat part and worked with them (not fully understanding their nature) but why?
type TMyRec = class s: string; n: integer; end; var MyRec: TMyRec; PRec: ^ TMyRec; begin // But MyRec is now null, which memory area can PRec start to refer to? PRec: = @ MyRec; PRec ^ .S: = 'Data string'; // Using the pointer, the string field of the record is changed PRec ^ .N: = 256; // Changing the numeric record field using the pointer end;
Everything is super, everything is great and works. But why bother if the next entry also works great?
var MyRec: TMyRec; begin MyRec: = TMyRec.Create; MyRec.S: = 'Data string'; MyRec.N: = 256; end;
In general, I have a bunch of questions on pointers that I can’t even formulate
I would be grateful for any information that explains why pointers are needed in everyday life
Answer 1, authority 100%
A pointer synonym is link.
There is memory, there is a reference to memory.
TClass in the procedure, a pointer (reference) to the object will still be passed, not the object itself.
record without a pointer, the entire piece of memory will be transferred to the procedure, not a reference, that is, the complete structure.
The pointer is inherited from Pascal even before OOP, that is, when there were no classes yet.
In Pascal, there are no classes like TList, and in order to do something similar, you need to fence your garden:
TList = record
PList = ^ TList
That is, pointers are needed mainly for
record and for compatibility with Pascal
Answer 2, authority 90%
Let’s stop at
// But MyRec is null now
Everything is great, everything is great and works.
The local variable
MyRec before assignment is not
nil , but has an arbitrary value (garbage). You are just in luck, because in the following lines you write to an arbitrary memory area, and the consequences of this may be the most unexpected.
Remember in Sudden Access Violation Delphi 10.1 Berlin I changed your code
try Props: = getProps; ... finally Props.Destroy; end;
taking the assignment out of
Props: = getProps; try ... finally Props.Free; end;
The meaning of the line assigning the value
Props outside the
try / finally block is that in case of an exception, inside
getProps , inside
finally the code will not hit, and there will be no attempt to free the memory pointed to by the uninitialized local variable
Another correct option:
Props: = nil; try Props: = getProps; ... finally Props.Free; end;