dynamic array. Does SetLength realloc memory?

[howardpc]

As so often in programming discussions subtle differences in meaning (or hidden or unconsidered ambiguities in meaning) can trip up clear communication.
Marco prefers "null-terminated" to mean what it does in C, namely that the presence of a #0 terminates the string, and any subsequent characters are not part of the string - if they exist they are only unconnected garbage.
Many Pascal coders tend to use "null-terminated" to mean "ansistring": namely that the end of every ansistring has a terminating #0 appended to it (by the compiler - this is not visible to the programmer without peeking at memory).
For any Pascal ansistring which contains only one #0 the two meanings turn out to be equivalent. For other cases "null-terminated string" comes to denote distinct, different entities in each meaning.
Ansistrings are really simulated null-terminated strings in the C sense. It's great that they give the best of both worlds (sensible Pascal string behaviour with built-in length and reference-count storage) and full PChar C-like string-as-an-array functionalilty.

[anna]

...
  FillChar(buffer^, len, #0); // correct Pure Pascal Form
...
I recomend the pure pascal form as long as you don't need to start a fill at a specific index

'Pure Pascal Form' is not allowed:
http://img826.imageshack.us/img826/706/grmz.png
So it's more understandable to use pointers, as it recommend here http://community.freepascal.org/bboards/message?message_id=266412&forum_id=24084
 

Code: [Select]

type
  // can use char here also
  BArray : Array[0..1] of byte;
  PByte : ^BArray; But it's not clear , why [0..1]? Why not [0..3]? I see it does not matter, just make array static. But such coding is some kind of trick.

[Leledumbo]

Thanks. But I never knew that dynamic array is pointer.

There you go

Clearly I confused you

Clearly I start the confusion. Indeed null-terminated sounds like null character terminates the string, but it's a guarantee that there will always be a null character at the end of the string. What's the best phrase to say this?

[User137]

Code: [Select]

type
  // can use char here also
  BArray : Array[0..1] of byte;
  PByte : ^BArray; But it's not clear , why [0..1]? Why not [0..3]? I see it does not matter, just make array static. But such coding is some kind of trick.

That is tricky, but it only matters to compiler hints when it comes to rangechecking, you can even use [0..0].

Code: [Select]

type
  BArray : Array[0..0] of byte;
  PByte : ^BArray;

var pArr: PByte; n: integer;
begin
  pArr:=AllocMem(10);
  pArr[0]:=1; // This is ok
  n:=1;
  pArr[n]:=2; // This is ok
  pArr[1]:=2; // Compiler may warn out of range, but it would still work
  // If it was array[0..1] of byte, or even [0..32767] or something, compiler would be happy.
  // The extra range doesn't increase memory used either, it's just based on your needs.
  ...
  FreeMem(pArr);
end;And i wouldn't recommend using AllocMem, ReAllocMem over SetLength dynamic arrays, just because they are that tricky to use, and not feel like in "spirit" of pascal language.

[sam707]

...
  FillChar(buffer^, len, #0); // correct Pure Pascal Form
...
I recomend the pure pascal form as long as you don't need to start a fill at a specific index

'Pure Pascal Form' is not allowed:
http://img826.imageshack.us/img826/706/grmz.png
So it's more understandable to use pointers, as it recommend here http://community.freepascal.org/bboards/message?message_id=266412&forum_id=24084
 

Code: [Select]

type
  // can use char here also
  BArray : Array[0..1] of byte;
  PByte : ^BArray; But it's not clear , why [0..1]? Why not [0..3]? I see it does not matter, just make array static. But such coding is some kind of trick.

I apologize : I forgot to mention that pascal language, normally, is a 'strong typed' language and it is an implicit evidence to me for years, so I gave the rule without a working example out of 'Traditional' pascal programming.

Here it is :

Code: [Select]

procedure TForm1.OnBtnClick(Sender: TObject);
type
  buf_byte_ptr = ^buf_byte;
  buf_byte = array of byte;
var
  buffer: buf_byte;
  ptr: buf_byte_ptr;
begin
  setlength(buffer,10);
  ptr:=@buffer; (* must be get after SetLength allocation *)
  FillChar(ptr^,10,0);
then it works for open arrays , it also works for array [1..10] , array [10..19], array[0..9],..,.., of byte, without the SetLength line in the above code snip

[BeniBela]

By the way what is the maximal size of a dynamic array on 64-bit platforms?
MaxInt or MaxInt * sizeof(an array element) ?

[sam707]

By the way what is the maximal size of a dynamic array on 64-bit platforms?
MaxInt or MaxInt * sizeof(an array element) ?

I assume unsigned longint for arrays of byte, but I don't mind at the moment lol.

and what if I have a sort of

Record =
  key : integer;
  alpha : float;
  pixmap: picture;
end;

dynamic array of that record

SetLength(10) would allocate 10 of these records , real length would be SizeOf(record type) * Length

so you need to clarify your question about max size on computers able to have 16Terabytes of ram ... 765000 records of 1 byte? 960000 records of 12500 bytes (containing pixmaps for example) ? aproaching an answer is then difficult, and/or doesn't make sense

[BeniBela]

so you need to clarify your question about max size on computers able to have 16Terabytes of ram ... 765000 records of 1 byte? 960000 records of 12500 bytes (containing pixmaps for example) ?

Assuming unlimited RAM (e.g. fpc running on a Turing machine) and 64 bit pointers

Can you use it all with an array, or is there some "bug" limiting the size to 2 or 4GB ?

[Leledumbo]

By the way what is the maximal size of a dynamic array on 64-bit platforms?
MaxInt or MaxInt * sizeof(an array element) ?

2 GB (SizeInt)  AFAIK, the structure is not platform dependant.

[User137]

...

Code: [Select]

procedure TForm1.OnBtnClick(Sender: TObject);
type
  buf_byte_ptr = ^buf_byte;
  buf_byte = array of byte;
var
  buffer: buf_byte;
  ptr: buf_byte_ptr;
begin
  setlength(buffer,10);
  //ptr:=@buffer; (* must be get after SetLength allocation *)
  ptr:=pointer(buffer);
  FillChar(ptr^,10,0);Fixed. You were getting pointer of pointer, and it caused SIGSEGV on FillChar.

[sam707]

Fixed. You were getting pointer of pointer, and it caused SIGSEGV on FillChar.

not sure you fixed something , what I did write I tested it and compiles fine by me

by the way
 since turbo pascal 2 or 3 the '@' is used to get a typed pointer (and you use it everytime when you need to set a OnEvent procedure manually

ex :
  type TMyForm = class(TForm)
  ...
  procedure StoreMousePos(Sender: TObject);
  ...

  MyForm.OnMouseDown:=@StoreMousePos;

so assigning an 'untyped' Pointer() to a typed pointer variable in my snippet, as you do, is like saying a white hat is a hat that is white

sorry , but lol

Well, as long as it works for you, and you have the concept to do things on arrays by procedure calls without the need to know their indices, but their lengths , its all good ! I guess

Enjoy !

All the rest is litterature and lost semantic discussions

[User137]

Yes it compiles but it crashes when run. You forgot that buffer is pointer, meaning that you can say:
buffer:=@buffer[0]

When you do ptr:=@buffer, it means ptr:=@@buffer[0]
further on you do FillChar(ptr^,10,0); , which does:
FillChar((@@buffer[0])^,10,0);
= FillChar(@buffer[0],10,0);
So what you are filling is address of the data, not data itself.

Also saying pointer(buffer) is a typecast, and means different than @buffer, it didn't compile when i tried simply ptr:=buffer, which is what we are after.

[BeniBela]

By the way what is the maximal size of a dynamic array on 64-bit platforms?
MaxInt or MaxInt * sizeof(an array element) ?

2 GB (SizeInt)  AFAIK, the structure is not platform dependant.

Which is of course completely wrong, because sizeint = int64 on 64-bit platforms.

So that does not rule out 8 EB

[marcov]

As so often in programming discussions subtle differences in meaning (or hidden or unconsidered ambiguities in meaning) can trip up clear communication.
Marco prefers "null-terminated" to mean what it does in C, namely that the presence of a #0 terminates the string, and any subsequent characters are not part of the string - if they exist they are only unconnected garbage.
Many Pascal coders tend to use "null-terminated" to mean "ansistring": namely that the end of every ansistring has a terminating #0 appended to it (by the compiler - this is not visible to the programmer without peeking at memory).

Correct, and to make that difference, we call that a trailing #0. (since it doesn't terminate, i>length(s) terminates)