Hi
I have a question about dynamic strings and memory allocation. If you look at my example underneath, I depend on that a dynamic string always is assigned memory space in one connected block. But will that always be the case in various operating systems.

Carsten

Function Sum(p:pointer; len:LongInt):LongInt;
Type
  a_typ=array[0..pred(maxLongInt)] of byte;
  a=^a_typ;
var
  i:LongInt;
Begin
  result:=0;
  for i:=0 to len do
    result:=result+a(p)^[i];
End;
Procedure test;
Var
  s:ansistring;
  i:integer;
Begin
  s:='Something';
  for i:=0 to 100000 do
    s:=s+'Test';
  if Sum(@s[1],length(s)) = 0 then
    halt(0);
End;

Med venlig hilsen
Carsten Bager

BEAS A/S
Brørupvænget 10
DK-7650 Bøvlingbjerg
Tlf. : +45 9788 5222 Fax : +45 9788 5434
www.beas.dk

Carsten Bager wrote

If you look at my example underneath, I depend on that a dynamic string always is assigned memory space in one connected block.

As the compiler allows for assigning a string to a pchar, the strings need to be compatible to C strings. Thus:
- The content starts at the location the pchar points to and fills consecutive addresses
- a $0 character is appended after the last relevant character.

Of course the OS is free to use the mapped hardware RAM address in a way that for DMA the string content might come in separate chunks.

Is this what you mean ?

- Michael

Yes, the data of a dynamic string is contained in one connected block.

The data of 2 dynamic strings may of course reside in 2 different blocks, i.e., it it not correct to say that all string data of the program is in the same connected block.

Michael.

Why not just skip all the encoding uncertainity of strings and use an array of byte/char?

It'll probably be a lot faster too

In our previous episode, Carsten Bager said:

0..len is len+1 items.

s[1] length(s) implies "lenght(s)" items. IOW the sum routine also adds/accesses the final zero.

Yes

Thanks

Carsten

My code was just an example, to illustrate what I was aiming at. It is not actually used. But I think you have a point

Carsten

Why not just skip all the encoding uncertainity of strings and use an array of byte/char? It'll probably be a lot faster too

Hi everyone,

Wait, I'm slightly confused. It seems people are talking about two different things:
1. Continuous memory as seen by the program running.
2. Actually physically contiguous memory.

It was my understanding that strings and dynamic arrays are allocated as a single block, and thus from the program's point of view, their contents should be continuous. (Short strings certainly are!). If the OS is using VM Mapping to convert two blocks of free memory into a single block for your program, I assume that would affect an array of byte just as much as a string. (Am I missing something?)

Thank you,
Noah Silva

2013/7/16 Carsten Bager

Noah Silva wrote

Wait, I'm slightly confused. It seems people are talking about two different things: 1. Continuous memory as seen by the program running. 2. Actually physically contiguous memory.

If you don't do hardware related things like DMA, you don't need to bother about this difference.

It was my understanding that strings and dynamic arrays are allocated as a single block, and thus from the program's point of view, their contents should be continuous.

Correct.

(Short strings certainly are!). If the OS is using VM Mapping to convert two blocks of free memory into a single block for your program, I assume that would affect an array of byte just as much as a string. (Am I missing something?)

Correct.

-Michael