David Heffernan

Which platform doesn't have good C and C++ compilers?

Those aren't facts though. If you are going to make a claim, back it up with credible evidence. Just because 45 said it, doesn't make it true.

That's surely not a problem with LLVM per se, rather the Delphi compiler on top of LLVM?

Win64 also I believe

Writing a tool is how I would approach this. Learn a language like Python so that task like this can be done very easily and quickly. Of course, an even better solution is to fix the process that is generating erroneous code in the first place.

Wouldn't you just add the commas? I mean, how many lines of code do you have with this mistake in?

Is this the only error that you want to be fixed automatically?

Pretty bad reasoning. If it's for paid customers only, then there's no security in case Emba go bust. "Because we love Delphi more than you do." How to win friends and influence people.

I don't think that this is encryption. And in any case, it's probably worth knowing that the password can be removed trivially.

Being able to manage the lifetime of classes is not an expert skill. It's well worth learning how to do it. Likely in your case you have somewhat tangled code into which you are jamming these classes. The difficulty is not that TList is hard, or that lifetime of classes is hard, but refactoring large code with different standards is hard.

When done right, it is simpler and cleaner to code using higher level constructs. Sounds like you are blaming the tools.

Aren't you meant to do work in a background thread?

Herd immunity springs to mind

https://stackoverflow.com/a/4497572/505088

Spend the time to get the deployment right and it's no problem. If you can deploy a single exe file then you can deploy a dll alongside it. If anyone is complaining then perhaps you aren't deploying correctly. I wonder, you aren't trying to deploy to system 32?

You can read the code to find out

If you don't have those versions, you don't need to do that.

Knowing the version where things changed doesn't influence how you resolve the warnings

That's not the same as starting from scratch. Also, didn't you have trouble with bugs in you asm code in your bigint library?

Well, that's exactly what I have been arguing for. It seems utterly insane to me that this task is handled at runtime when it can be handled at compile time. Anyway, as I understand it the record dtor would run in addition to the RTTI based finalization code. So adding a dtor could only ever make code slower.

True years ago, but these days not so. Just put some code through godbolt and marvel at the code that it generates. You don't have to get that complicated before you see the compiler spotting optimisations that are very far from obvious. Optimisers now have deep knowledge of hardware architecture and can use that to make choices that are beyond almost all human asm programmers.

That's because your button event handlers run busy message loops waiting for the child processes to finish. Your mistake is to run those busy loops in the main thread. You should consider running those loops in dedicated threads, and obviously remove the message processing. You code leaks the process handles and has other problems. Duplicating the code is a bad idea. You should be using CreateProcess to create processes. Fundamentally I would say that your main issue is that copying code without understanding it is a bad idea. You then become unable to maintain it and are unable to critique it.

Why would we want to finalize records manually? What a terrible retrograde step.

I don't much care what you like, or don't like. My point was that there exist plenty of compilers that can emit optimised code that is exceedingly efficient, and extremely hard to beat by humans writing code themselves.

You mean language rather than compiler.