David Heffernan

Maybe so. But my point about how to deal with getting a pointer from a string that may be zero length stands. So long as the use of the pointer respects the zero length and doesn't try to de-reference it.

The correct solution, in my view, is to pass Pointer(RawMessage) rather than @RawMessage [1]

This can easily happen. It's really common. Programming mistake in the app manifests as an exception raised in vcl code. Nothing interesting to see here.

Here's what to do. First of all you need to understand the R code. You need to know what it's purpose is, and how it achieves it. You will need a clear understanding of what data types are expected to be passed to, and returned from the function. You may need to talk to the author of the code, or learn enough R to work it out yourself. Once you have a clear understanding then you will be in a good place to write an equivalent function in Delphi. Good luck.

If you comment out all of the code then the library will compile. And we all know that once a piece of code compiles, the job of the programmer is done.

Index out of range error. Stack overflow. Invalid operation. Is that how this works?

So make the necessary changes. Or hire a programmer.

I can't make any sense of what you are asking here.

Perhaps the bug is in some other code in the user's program. One of the recurring themes with questions like this is that the asker often doesn't know how to use, or even realise the value, of the debugger. Re-writing the code for them doesn't help them learn that.

Do you understand what the error message tells you? You are using an index i outside the range 0 to Count-1. You can use your debugger to find out which indexing operation is out if bounds. Debugging by looking at code can be quite hard. Delphi has a powerful debugger for such moments.

Do you know this?

The reason I asked for a minimal reproduction is that by making one, and making it minimal, you'd have learnt a good debugging technique. Instead you posted loads of spurious code. But the act of curltting it down to a minimal reproduction would have led you to the error. Then again, the compiler told you which line the error was on and somehow you missed that information.

Can you make a minimal reproduction and post it here as formatted code rather than screenshots.

What proportion of the overall time your program takes for the task, is the operation you are trying to optimise in this thread?

You aren't. The code in @corneliusdavid post is what you should do.

No I don't think so. Follow the actual rules. When you create an instance, destroy it in the same context that you created it.

I think Arnaud's synopse library has a bunch of more optimised mem copy routines

You will only consider graduates with computing degrees? Seems like that would rule out a lot of good candidates.

Interlocked is always going to be terrible here. Local accumulation, join, and then a final summation would be better. A magic parallel=true flag is fanciful. Why look at Python. Surely look at the various C++ compilers?

The value of the summation an be evaluated statically. I don't think any compilers do this, but I could be wrong.

A really good compiler would remove the loop and just turn it into a simple assignment

The familiar refrain, but the message has not landed yet

TIniFile uses deprecated Windows APIs that haven't been safe to use since 32 bit Windows was release nearly 30 years ago. So yeah use TMemIniFile which has a native Delphi INI parser that won't cause you such trouble. Never ever use TIniFile is the rule here.

I think I'd write a custom dict for this.

I don't think any amount of care can solve the issues there