Chris Miller
Programmer
Well, Martina already said Chen got rid of the overall 2GB limit of FPT files. And will allow larger strings in 10.2.
You're showing you can now also write and read longer than 2GB files with the file functions FREAD and STRTOFILE. I wondered about the maximum string variable length. You show can grow larger now, too, so I assume that is VFPA 10.2 now.
I talked about a memory management nightmare, that is because of how strings are stored in variables and memory, not only in VFP, with a length and a pointer to allocated memory. VFP allocates the length of the string to store, so an operation that makes a string longer, like lcText=lcText+'.' will lead to allocating a new memory block 1 byte larger, as VFP doesn't reserve more bytes for spare usage. And that leads to a lot of memory allocations and deallocations when operating on large strings. And since 32bit processes only can have 4GB of process memory you can easily clutter the memory and peak the need for garbage collection, if you would allow large memory strings. Well, it's not a memory management nightmare for us, using VFP, it's a nightmare to program variable handling.
That is to say that Chen (hopefully) has done a good job that will make use of ideas like provisionally allocating more memory allowing strings to grow without needing to full copy them in RAM just because they grow by 1 byte. I'm confident it all works, but I'm still saying it's not necessary. At least not to me. Have fun with VFPA, stanlyn.
Chriss
You're showing you can now also write and read longer than 2GB files with the file functions FREAD and STRTOFILE. I wondered about the maximum string variable length. You show can grow larger now, too, so I assume that is VFPA 10.2 now.
I talked about a memory management nightmare, that is because of how strings are stored in variables and memory, not only in VFP, with a length and a pointer to allocated memory. VFP allocates the length of the string to store, so an operation that makes a string longer, like lcText=lcText+'.' will lead to allocating a new memory block 1 byte larger, as VFP doesn't reserve more bytes for spare usage. And that leads to a lot of memory allocations and deallocations when operating on large strings. And since 32bit processes only can have 4GB of process memory you can easily clutter the memory and peak the need for garbage collection, if you would allow large memory strings. Well, it's not a memory management nightmare for us, using VFP, it's a nightmare to program variable handling.
That is to say that Chen (hopefully) has done a good job that will make use of ideas like provisionally allocating more memory allowing strings to grow without needing to full copy them in RAM just because they grow by 1 byte. I'm confident it all works, but I'm still saying it's not necessary. At least not to me. Have fun with VFPA, stanlyn.
Chriss
