David Heffernan

What I propose works and it's better to avoid strings here.

Neither. Spawn of satan, should never have been published. In your case do all the behind the scenes work using integers and then divide by 10 just when you need the actual value. Or use a decimal type like currency.

I'd definitely remove the pointer check you just added. Surely that's just going to make things slower.

Don't think performance is an issue with TArray<T> and using it makes you code better able to work with other generic code.

Any reason why you aren't using TArray<Integer>?

This risks range check errors so I'd use Pointer(A)^ and similar for B. You could still save one of the lengths to a local to avoid getting it twice.

Not much point having three calls to Length and in fact the zero length check can be skipped and rely on CompareMem to know what to do when passed a size of zero.

First compare their length then do a CompareMem if the lengths are equal

I once went into our local hardware store to buy a posidrive screwdriver, because I had to do something with a bunch of posidrive screws. The guy in the store scoffed at me and said that they didn't stock posidrive screwdrivers because posidrive screws were a stupid idea. This store is no longer in business.

Agreed, but the issue is not one of type safety, as you stated.

How are you expecting anybody to translate this without there being an agreed curl library. Do you know what curl is?

You don't need to be a C programmer to translate this. You just need to understand the basics of curl. Do you have a Delphi curl library to hand?

no extra type safety is gained by using a record over an array

Invariably this error is a 32/64 bit mismatch

Could you explain the requirement in more detail? I think that might help us understand how to solve the problem.

Remember that font glyphs are usually vector images and so rasterising into an image list may not be ideal, depending on your usage. My guess is that rasterising every glyph from a font ahead of time is terribly wasteful. You may run out of resources. Why don't you just draw each glyph on demand when you need to?

It will do because it knows the size of the fixed length array at compile time.

Evidence?

Same time for both versions for me, using 64 bit release build with XE7. I'm quite confident that your diagnosis is not correct.

In terms of accessing the memory, then there's basically no difference in performance between heap allocated and stack allocated arrays. The performance difference comes in allocation. If you are going to allocate such large arrays then the time spent working on them surely dwarfs the allocation cost. The other thing to note is that your stack is typically going to have a size much lower than the arrays you want to work with. So even if you could declare such huge arrays as fixed size, they won't fit I. The stack. In other words heap allocated dynamic arrays are the only option. Probably your next move is to revisit your benchmark and understand how you ended up with the erroneous view that heap allocated memory is slower.

No, I mean that linking C++ static libraries is exceptionally hard, because where do you get the runtime support from? No. It calls the standard Delphi MM. Also, there's no concept of freeing heap memory directly. That makes no sense. You always have to free from the same heap that was used to allocate.

Yes it's exceptionally hard. Just put the code in a DLL.

Would you like to trisect the angle with ruler and compass while you are it too? Seriously though, I wonder if it's realistic to look for a solution without actually changing anything.

In what version of Delphi is this? Are you sure that it raises an exception? If it does then that is a change of behaviour from the XE days.

Use an old version of Delphi that supports XP. Or give up supporting ancient versions of Windows.