Dalija Prasnikar

Well, that discrepancy could have been solved with 1-based arrays. Delphi wouldn't be the first nor the last language having them. See: https://stackoverflow.com/q/9687039/4267244

That is in no contradiction with what I said, as TP started as extension of Standard Pascal. Anyway, 1-based string types never caused any problems until they introduced 0-based strings for mobile compilers and the whole hell broke lose.

This was due to Turbo Pascal legacy.

Each core has its own FPU. It is possible that some older multicore processors shared single FPU, but even in such case each thread would have access to its own "FPU data copy". If those values would be shared among threads, then different threads could trample upon results of other thread calculations.

FPCR is part of the FPU and its state is preserved during context switch. So each thread works with its own state that is independent of others. If you only handle floating point state directly through FPCR it will be thread-safe. Problem with Delphi is that it throws global variable into the equation and then handles FPCR with the help of that global in thread-unsafe manner, which can then leak "wrong" state into different thread.

FPCR can be set in a thread safe manner. it is just that Delphi RTL doesn't do that on Windows platform. David has written about it see and https://stackoverflow.com/a/27125657 I have also written about it in my book Delphi Thread Safety Patterns. Working with masked FPU exceptions is the norm across various languages. Also even before Delphi 12, all other Delphi platforms except Windows VCL has masked FPU exceptions. So if you had written FMX application it would have been working the same way it is working now across the board. So the best option is moving to the masked FPU exceptions as this will create the least amount of trouble for the future. Of course, if you are dealing with Delphi built DLLs which don't honor that, you will have to adapt. Another option is to unmask exceptions and proceed as usual, but doing that in multithreaded application is not advisable unless you also patch the RTL as it is not thread-safe. Even having masked FPU exceptions is not thread-safe, but it is much harder to trigger the issue and much easier to avoid RTL API that uses unsafe parts than with unmasked exceptions.

Well, the problem is technically in the LLVM, so blaming the LLVM is fine 😉 But again, also it is not technically a bug in LLVM, but merely lack of certain feature, which is not so easy to add at this time.

It is language related, more precisely compiler related (LLVM backend). The hardware part is related to exceptions that happen in hardware which cannot be caught by LLVM backend. Old Delphi compiler (Windows one which has custom frontend and backend) can catch those because it was designed that way. LLVM origins are in C++ which on language level does expect catching such exceptions, so there was a "design mistake" in there that is now very hard to change, to accommodate slightly different languages. Most common hardware exceptions are access violations (accessing nil or invalid memory) and floating point exceptions. See: https://dalijap.blogspot.com/2023/12/catch-me-if-you-can-part-ii.html Plenty of languages are designed around notion that if they encounter certain types of issues they should just crash the whole application instead of trying to recover. Now, such behavior reduces the chances of certain vulnerabilities, but on the other hand makes very hard to deal with certain scenarios, especially gracefully detecting and handling bad input data, and they put a lot of more pressure to the developer to imagine all kinds of potential failures and prevent them explicitly in code. So in Delphi (Windows platform) accessing nil pointer will result with exception which you can catch and handle, so you can write code that will not check for nil instance and just try to access it and if it fails you can have exception handler that will handle such situation without anything bad happening. On the other hand, if you have such code in Swift (which also uses LLVM) your application will crash and burn and you cannot recover from such error at all. You need to pre-emptively check whether instance is nil when you expect it might be to avoid accessing nil instance. In Delphi compilers with LLVM backend, you can still catch nil instance access and recover, you just cannot catch it in the immediate code block, but it must be in separate procedure or method and only outside exception handler can catch and gracefully handle such exception.

I would use TypeInfo instead of RTTI as it will be faster. This requires System.TypInfo procedure TMyThingy.SetEnumPropertyValue(const AValue: string); begin PByte(@FEnumProp)^ := GetEnumValue(TypeInfo(TMyEnum), AValue); end; You should pay attention on enum type size and use appropriate sized pointer when casting PByte(@EnumProp)^. This will also raise out of range exception if passed string does not match to any value in TMyEnum. You can catch that and set it to some default value if needed.

If you really need to have multiple references to an object, then use interfaces and ARC to manage lifetime. If not, then you will have to invent similar mechanism for managing the lifetime.

This is always the greatest benefit. Integer math is still faster. Just not that much. And division is still more expensive than multiplication. Anyway, when it comes to any optimizations, it always goes hand in hand with measuring. and making sure that you really need optimization in the first place and are not making a bad trade-off by complicating the code.

I have no idea what is in that book, but I doubt that it is very much obsolete. Math behind it does not change. Nor the fact that some operations will always be more expensive than others, no matter the CPU.

This is classic AI spammer tactic. Post AI on random posts to make it look like user is actively participating, and then separately they also post blatant spam.

I never used that setting so there might be issue with that one. But, when you run the wizard at one point you will also have Three buttons under the settings tree: Update Migration, Version Migration, and Computer Migration. You should choose Version Migration when migrating form one version to another. It is probably better to export settings to file and then import after the installation. But even if you do that you need to make sure that you choose Version Migration. The fact that IDE was trying to load packages from older version is a signal that you have imported wrong settings.

Update migration is wrong option. It is used only for same version updates. You need to choose Version migration. 11.x and 12.x are not compatible,