Hi all,

Sorry if this is trivial, but I'm sick of it :)
I'm using fpc to convert my (originally delphi) code to read and write ini style files, however writing will not work as I want, the data in the pointer keeps getting filled with junk.

I'm using getMem, and reAllocMem functions to create dynamic arrays of strings. The writeINI function reads the entire file in, but doesn't even do that correctly.

I have a test program that uses the same idea, and it works perfectly, so I'm very bewildered :(

attached is the code if someone would like to have a look at it, please.

thank you
James

Sorry, forgot to include the tokenizerclass.pas

cheers
James

Thank you, I"ll try that.

Thank you, it works very well now that I understand how them damn pointers work. One question though, how do you free the pointer's memory?

freeMem(tmpStrings, sizeOf(String) * (N));

cheers
James

But getMem and reAllocMem allocate a number of bytes on the heap, wouldn't you have to free that number of bytes using freeMem(pointer, n) ?

cheers
James

Btw, I'm using short strings, so I think it'll be ok for now...

Ok thank you very muchly :) You've been a great help.

Hello, James!

I found an error at GetMem / ReAllocMem: Your code:

  getMem(tmpStrings, 100);
  {reAllocMem(tmpStrings, (I + 1));}

reserves 100 or (I + 1) BYTES, but you need space for 100 or (I + 1) STRINGS, i. e. the code should be:

  getMem(tmpStrings, SizeOf(String) * 100);
  {reAllocMem(tmpStrings, SizeOf(String) * (I + 1));}

Even then, I don't know if fpc behaves correctly converning deallocation when <String> defaults to <AnsiString>. Maybe somebody else can respond to this?

Another note: Please replace tabulators by spaces when posting code.

Hope this Helps.

Anton Tichawa.

----------

"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte Berechnungen einzuweben."

Doris Langley Moore: Ada, Countess of Lovelace (London 1977).

----------

Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email:

----------

Hello, James!

That's exactly what I meant: I'm not sure if fpc is able to keep track of the destruction of the strings in case of AnsiString. You might check it by displaying the total free memory before and after the deallocation of tmpStrings. But one of the developers might answer this question in a few seconds, wheras I would need half an hour .. how urgent is hsi question?

HTH,

Anton Tichawa.

----------

"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte Berechnungen einzuweben."

Doris Langley Moore: Ada, Countess of Lovelace (London 1977).

----------

Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email:

----------

you wrote

freeMem(tmpStrings, sizeOf(String) * (N));

No, only:

freeMem(tmpStrings);

Read the Manual - Free Pascal Programmer's Manual, Section 4.5, "Writing Your Own Memory Manager" - because that's what you're actually doing.

HTH

Anton Tichawa.

----------

"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte Berechnungen einzuweben."

Doris Langley Moore: Ada, Countess of Lovelace (London 1977).

----------

Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email:

----------

Hi,

But getMem and reAllocMem allocate a number of bytes on the heap, wouldn't you have to free that number of bytes using freeMem(pointer, n) ?

No, Free Pascal keeps track of the allocated size for a pointer created with GetMem/ReallocMem. They need this information for heap management, so it's a good think to use this information to save one procedure parameter, which is a lot. If you want to determine the number of bytes to deallocate, you may do this by using:

  Function FreeMemSize(var p:pointer;Size:Longint):Longint;

Definition:
FreememSize
This function should release the memory pointed to by P. The argument Size is the expected size of the memory block pointed to by P. This should be disregarded, but can be used to check the behaviour of the program.

I think with FreeMemSize you may corrput the heap, so be careful with it!

Anton.

Anton Tichawa wrote

That's exactly what I meant: I'm not sure if fpc is able to keep track of the destruction of the strings in case of AnsiString.

It is, as long as the type of the variable is clear when getmem/freemem is called (getmem also needs to know it, because if you use ansistrings, the memory must be cleared after it's allocated). What I mean is that

***
type
   ta = array[0..9] of ansistring;
   pa = ^ta;
var
   p: pa;
begin
   getmem(p,10*sizeof(ansistring));
   readln(p^[0]);
   freemem(p);
end;
***

Will correctly release all memory. If you change the freemem into

freemem(pointer(p));

however, then the memory allocated for the array will be freed, but the ansistring won't be finalized. This may seem strange at first sight, but it can occur when people construct generic datacontainers. It's one of the reason I dislike ansistrings and all the other things that require initialization/finalization: it completely breaks when you go low-level and as such it doesn't mix well with legacy Pascal code (and as your question indicates: it's not always clear at first sight whether a certain construct will behave correctly, you just have to know how far the compiler magic extends).

Jonas