David Heffernan

What will it take for Delphi programmers to give up on the idea that strings and byte arrays are the same thing!

Random returns 32 bits of randomness, why only use 16 of them? In other words, can't you do this with two calls to Random rather than four. Furthermore, Random is a pretty low grade PRNG. Depending on what you intend to use this for, you may want to use a better PRNG.

These helpers are often just copied from .net, and .net strings are immutable. Here is the .net property: https://docs.microsoft.com/en-us/dotnet/api/system.string.chars?view=netcore-3.1

What calling convention is the function? If it is register then that is a problem. Make sure it is stdcall. A websearch for pinvoke will tell you how to call this function.

Conceptually a list class is the same as an array. For sure it has extra convenience functionality, but it is still a random access array. So my philosophy is that consistency is achieved by having lists match arrays. I'd have the range checks conditional on RANGECHECKS. Indeed that is how I do it in my personal collection library.

You have to enumerate all the files and copy them. Put these files into a double null terminated list. COM should not be initialised here. It needs to be initialised by the owner of the thread.

I have a unit with 53kloc (hangs head in shame)

This is a branch or a fork in your SCM system. If you aren't using SCM then that's your problem right there. Solve that problem first.

Don't think so https://en.cppreference.com/w/cpp/language/enum

That's what scoped enums are meant for

This is exactly the issue that scoped enums solves already.

That's XE7. It seems to me to be folly to design your code based on an IDE tooling issue, and especially one which is soon to be resolved. Further, the issue at stake here, as always when coding, is far less about the experience when writing code, as the experience when reading code. It's not worth it to reduce the readability of your code to give a minor easing to your experience when entering the code.

Following on from my comment about complexity, I'm wondering what's wrong with this: You don't need to remember anything. Why are you seeking complexity here? You seem to be trying to solve a problem that simply does not exist.

Why is that harder than remembering something else, as you seem to want to do? Why is complexity so compelling?

You'd be far better off using scoped enumeration. It forces you to fully qualify the enumeration. Instead of deciding what the solution is beforehand, you are better off understanding the options offered by the language and working with the language, not swimming against the tide.

It all went downhill when Borland decided that function return values were actually var parameters. Which means that in the case of managed types they get initialized by the caller. A function return value really should have pass by value callee to caller semantics.

What problem are you trying to solve? What's wrong with vHTMLReportType := htTemplate;

You missed step 1. Step 1: identify the bottleneck. It's a common mistake.

All this incredible noise, and all Mike needs is to simply time his own program...... It's really so simple.....

I don't really buy what Kas is saying above. Just time your actual program is usage scenarios that you care about. After all, why would care about the performance of code that you never run? You only care about the code that you do run, or your users run.

Because timing a for loop doing 1,000,000,000 iterations of nothing meaningful is nothing more than a low grade PRNG. Put something realistic inside the loop, and then time it.

It isn't. Hmm .....

Well, it's reasonable to wonder about that, and Stefan talked about that. But you actually spent a lot of time talking not about the codegen, but about performance. And the key point is that there is no performance difference for the two versions of the code that you presented, once you put the code in a context where it actually does something. After all, the code you showed doesn't initialise any variables, and just performs the exact same two comparisons on each iteration of the loop. Here's a question for you, why don't you compare the run time of your code, with code where your for loop is removed? I bet it will be faster with the for loop removed. And the code does the same thing with or without the for loop. Obviously that's silly because the for loop is meant to represent some real world code. But it's only meaningful in the context of actual production code. I've said it many times, but when you put your two variants into your real world program, you won't be able to tell them apart from the perspective of performance.

Can I ask again why you are timing something that has no relevance to the performance of the code that you care about? Once you time these variants in a real program, you will find that you won't be able to detect any difference in runtime. And then you will draw the conclusion that the best way to write the code is in a manner which avoids duplication of code, and which makes it easy to maintain. You'll likely also decide that there is no real gain in explicit inlining of the function here, and will stop doing that.

Records can be managed types