Christof,

>It's certainly true that VFP is as fast as the underlying C code, however, this doesn't mean that it's fast code. VFP is actually quite slow when it comes to string handling compared to C++.

I hope I didn't imply that VFP was totally as fast as C++, otherwise those couple of C++ DLL samples over on my website were a waste of time. *bg*

>The following program uses the standard approach to generate a 15 MB string:

I really don't know why you'd ever do 15,360 dual memory allocations, ie once for the result of the replicate() and then concatenate it to the other string. I wouldn't call the code a "standard approach" to allocating a big block of memory.

Also your second fast code is doing all of the memory allocation in one command:

lnAddress = HeapAlloc( GetProcessHeap(), 0, lnLoop*lnSize )

And then you are filling that block with the As 1000 at a time with the command:

memcpy_write( lnAddress+(t*lnSize), Replicate("A",lnSize), lnSize )

While it accomplishes the same thing it's two radically different solutions to the problem, the second one being an order of magnitude more complex, but it's also 3 orders of magnitude faster! So the code complexity would be worth it.

I didn't give specific example though of where if you had preallocated the memory in VFP, the code to use that buffer would be complex and slow because of the interpretive nature of VFP.

Say your buffer is filled with a character that would not occur in the final result:

gcBuffer = replicate( chr(255), 16000 )

now when you want to use the buffer you have to code something like:

i = at( chr(255), gcBuffer )
stuff( gcBuffer, i, len( lcString ), lcString )

Admittedly the memory write code you posted would probably do this faster than stuff() will. Although I don't know, stuff() might map directly to memcpy() in some cases.