How can a preprocessor (macro compiler) help here, when it runs at compile time, while time question was clearly about runtime storing of strings (mentioning New and block moves etc.)?
I assumed that the strings were being stored at runtime because storing them end-to-end at compile time was too tedious. If there is a static set of strings, then the Pascal Macro Compiler can store them without any wasted space. If additional strings need to be added to that set at runtime, it is easy to write a procedure to append them to the character array so that all of the strings are accessed the same way. This avoids the use of the New procedure, except if you use it for handling array overflow.
I don't know the internals of the GPC New procedure, but in various environments where I have worked in the past there was no guarantee that successive calls to New would allocate adjacent blocks of storage, hence no guarantee that there would be no gaps or wasted space. It all depended on what sequence of calls to New and Dispose had occurred earlier.
Frank Rubin
Contestcen@aol.com wrote:
I assumed that the strings were being stored at runtime because storing them end-to-end at compile time was too tedious. If there is a static set of strings, then the Pascal Macro Compiler can store them without any wasted space. If additional strings need to be added to that set at runtime, it is easy to write a procedure to append them to the character array so that all of the strings are accessed the same way. This avoids the use of the New procedure, except if you use it for handling array overflow.
I don't know the internals of the GPC New procedure, but in various environments where I have worked in the past there was no guarantee that successive calls to New would allocate adjacent blocks of storage, hence no guarantee that there would be no gaps or wasted space. It all depended on what sequence of calls to New and Dispose had occurred earlier.
You can never rely on successive `New' calls to return adjacent blocks of storage. That's not a reliable way to enlarge an array. And I don't know of any compiler for Pascal, or any other language for that matter, where such a thing would work. Sometimes there are special routines for that (in GPC the non-standard ReAllocMem, use with caution), otherwise you have to allocate a new array and copy the existing elements, or use another data structure that doesn't require contiguous memory, such as lists or trees.
Frank
On Fri, 8 Jul 2005, Frank Heckenbach wrote:
Contestcen@aol.com wrote:
I assumed that the strings were being stored at runtime because storing them end-to-end at compile time was too tedious. If there is a static set of strings, then the Pascal Macro Compiler can store them without any wasted space. If additional strings need to be added to that set at runtime, it is easy to write a procedure to append them to the character array so that all of the strings are accessed the same way. This avoids the use of the New procedure, except if you use it for handling array overflow.
I don't know the internals of the GPC New procedure, but in various environments where I have worked in the past there was no guarantee that successive calls to New would allocate adjacent blocks of storage, hence no guarantee that there would be no gaps or wasted space. It all depended on what sequence of calls to New and Dispose had occurred earlier.
You can never rely on successive `New' calls to return adjacent blocks of storage. That's not a reliable way to enlarge an array. And I don't know of any compiler for Pascal, or any other language for that matter, where such a thing would work. Sometimes there are special routines for that (in GPC the non-standard ReAllocMem, use with caution), otherwise you have to allocate a new array and copy the existing elements, or use another data structure that doesn't require contiguous memory, such as lists or trees.
Frank
May be, this ready to use unit may solve the problem(??): http://www.desy.de/~bohnen/gpc/units1/dictionary.pas http://www.desy.de/~bohnen/gpc/units1/doc/dictionary.pdf
Ernst-Ludwig
-
Contestcen＠aol.com -
Ernst-Ludwig Bohnen -
Frank Heckenbach