David Heffernan

This is the part I didn't watch, but yeah, that makes so much more sense now!

He's probably using UTF-8

It's a sign from above

Perfect hash only works if you can restrict your input domain, or am I wrong?

The thing is, how are you going to get to the stage where you have got a token that you know is a valid keyword? Perfect hashes are cool and all, but I wonder if this is the best example.

What seems missing to me is how to restrict the input data to be just valid typescript keywords.

I use option sets. They are in my repo and if I want to change the all my projects pick them up.

Nah, I'd go all the way to the latest. Multiple stepping stones is just adding extra complexity. The big change is Unicode. Everything else is simple.

The Delphi RTL can do this in multiple ways, as discussed here, and elsewhere, by me, ad nauseum.

Not strictly true. It depends on where they are coming from. It's much more complex than this blanket advice which I always regard as poor advice.

It's exactly as @Stefan Glienke said. The 32 and 64 bit hardware is different. On 32 bit there are 80 bit floating point registers used for intemediate values. On 64 bit there are not and all FP registers are 64 bit. Did you read the link I gave you? If you have not read that yet then this conversation is rather pointless? You first of all have to appreciate that these values cannot be represented exactly in binary floating point format. Perhaps your real problem is that you are using the wrong data types. Maybe you should be using a decimal data type so that you can represent these values exactly? What are these values? Sometimes floating point is correct, sometimes decimal is correct. Without context we can't know. Or perhaps you already know about floating point representability issues. Do you?

Here's some Python output that should help: >>> from decimal import Decimal >>> Decimal.from_float(1.015) Decimal('1.0149999999999999023003738329862244427204132080078125') >>> Decimal.from_float(3.015) Decimal('3.015000000000000124344978758017532527446746826171875') >>> Decimal.from_float(1.015*100) Decimal('101.4999999999999857891452847979962825775146484375') >>> Decimal.from_float(3.015*100) Decimal('301.5') And @Stefan Glienke explained why results differ on 32 bit because that uses an intermediate 80 bit extended register that will have different values for the closest representable value.

You are going to lose your mind when you learn that 1.015 is not representable, and when you write 1.015 in your delphi source code, the compiler turns it into the closest representable number which happens to be 1.0149999999999999023003738329862244427204132080078125 You might want to take a look at this famous question on SO: https://stackoverflow.com/questions/588004/is-floating-point-math-broken

Why should we do this?

You'd have the answer by now if you'd started stripping stuff out

What does the debugger tell you

There's also this technique

Simple. Develop in the lowest version that you wish to support.

That's not what AQtime does. Vtune is essentially analogous to AQtime but far more capable. You aren't going to find this magic solution that you want, whereby you wave a magic wand and your program is suddenly much faster. Optimisation though is going to take effort from you to understand your program. No shortcuts.

Buy a GPS watch. Or install strava on your phone.

I can't make any sense of this. Maybe an complete but minimal program would help, and knowledge of whether your process is 32 or 64 bit. Also, do you know about sysnative?

Well, true, but everything would break. So it's not going to change. And I think that's why it has been documented. I think it wasn't originally documented but at some point MS realised that this has become a contract that can't be broken.

I wish the language would require parens for parameterless calls.

An HMODULE has always been the base address of the module, as loaded into its process. And it's documented here: https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types#HINSTANCE

Stack location has never been repeatable. And as for the module, it starts at HInstance. As it always has. And DLLs have always needed to be relocatable. It's just Windows EXEs that previously could be relied upon to have a known start address. So yeah, change $00400000 to HInstance and it's all good.