Delphi's memory allocation for string

when a string variable is defined in a function, procedure, or method, because we know that the variable defined in the function, procedure, or method is a local variable, its memory is allocated in the stack, but here's a little detail we should note that for a local string variable with a size of 4 bytes, the 4 words allocated in the stack is not the whole of a string variable.

The answer is no, it saves only the size of the character variable and the value of the character variable in the stack. the memory address in the heap . , which means that the value of the character variable is not in the corresponding stack, but in the heap. We have learned that the memory allocated on the heap is for programmers to handle the memory release, and we have not processed the memory occupied by the variable when we use a variable of type string . What is the reason for this?

Here we are going to talk about The compiler's reference counting principle, precisely because it saves us a lot of trouble (of course, in some cases we are still careful, The reference count, in fact, is that this block of memory is referenced by several variables, which counts for this memory (may not be expressed correctly, but for the sake of good understanding), is a 1, there are 2 is 2, to this kind of push. When a string variable is used, the compiler automatically subtract its reference count by 1, and if the reference count is found to be 0 , the memory space occupied by the character variable is freed. It is important to note that the reference count will occur under what circumstances. If you define a string variable and assign it a value, the string variable reference count is 1, and if we define a string variable and assign the value of the first character variable to the second character variable, then the reference count will be raised to 2, note that The editor does not copy the value of the first character variable to the second character variable at this time, but only gives it the address pointer of the first character variable value. That is, the values of the first and second characters are in the same block of memory: However, when we access the character variable by accessing the array element or by modifying one of the character variables above, a "write copy" is thrown, and then the two string variables begin to use a different memory footprint. Because all of this doesn't bother the programmer, it's all done automatically by the compiler, so where do we have to be careful?

This is related to the DLL, we know that in the EXE program call DLL, EXE and DLL are each using their own memory manager, the trouble is here, if we call the DLL in an input function to return a string, we know that the string reference count is 1, EXE in the use of this string after the reference count minus 1, that is 0, according to the Convention, the compiler used to erase the memory of the string to release, OK, everything goes well, then the turn of the DLL processing, said EXE and DLL each has a memory manager, At this point the DLL does not know that the EXE has freed the string memory, and also to access the freed string, the string does not exist, where to visit. So the program is a problem, obviously this is what we do not want to see, in the use of DLLs, in order to avoid this problem, we can have a variety of solutions

1. Using memory-mapped files

2, DLL unit and EXE unit refer to SHAREMEM unit

3. Do not use the string type (note: Dynamic arrays, interfaces, and variant types also have a reference counting mechanism), instead of the Pchar type