David Heffernan

I mean, they've shown no interest in performance whatsoever, and even less interest in floating point code. It's as much as they can manage to vaguely support all the different compilers they have and keep them functioning.

This isn't the problem. The problem is in the incorrect header file translation. The project settings that you highlight should not be changed. They are just the reason why the code has been exposed as being incorrect. That exposure should be celebrated! It's very wrong headed to try to ignore such a mistake as you propose here.

Looks like this has always been broken but you just got lucky because the 64 bit handles happened to have values that weren't changed when your code truncated them to 32 bits. With the latest delphi your luck ran out because the values are now being changed by truncation, for whatever reason. But your code was always broken and you just got away with it. Be thankful for the new delphi version highlighting this. The mistake is in your translation of the header code. There are going to be a bunch of pointer sized types that you have erroneously translated as 32 bit longint or integer.

Would be weird to want to truncate a single (a well defined task) and insist on doing so in an inefficient way.

The point I think is that FMX projects masked exceptions previously by accident rather than design. Why should making an empty FMX project bring in all those units and change the floating point control state? I understand why the change to the default was made. I kind of agree with it. But changing your code to match isn't always going to be easy. I think it would be a huge task for any code base that is heavily numerical. I certainly wouldn't change.

I was interested to see different behaviour between VCL and FMX on Windows, in pre Delphi 12. I'm not sure that this is especially intentional. It happens because FMX.Platform.Win uses FMX.WebBrowser which uses FMX.WebBrowser.Win which uses System.Win.InternetExplorer which does this in its initialization FSetExceptMask(femALLEXCEPT); I guess it does this because this the IE library implementation expects exceptions to be masked. Similarly a default FMX app will use Winapi.EdgeUtils which also masks exceptions for the same reason. I actually think it makes sense to have all platforms behaving the same way and exceptions being masked by default. That being the platform standard on all of these platforms. Myself, I'm going to keep unmasking exceptions because my codebase relies on that. I hope that the Delphi RTL will continue supporting being used with exceptions unmasked.

I don't think that's the case. If you need to interface with a C++ codebase, then you need to create either a C wrapper, or a COM wrapper, but in each case you aren't limited to C++Builder. Whichever compiler you use to compile the C++, you compile the C wrapper, or the COM wrapper. The point is that the C or COM wrappers are compiler agnostic. But C++ code is, in general, not compiler agnostic. So you just need to compile your wrapper in the same toolchain as the C++ library. There are actually tools to create such wrappers. I'm thinking of SWIG. But there's no way that there's going to be a Delphi produced which can consume C++ libraries compiled by some arbitrary C++ compiler.

Because Delphi 1 could import functions from DLLs.

That's inevitable though isn't it. Because OpenCV is written in C++. For which there is no single binary interface.

This can already be done, and has been possible since Delphi 1

How much are you prepared to pay? What exactly does the job entail? You may be better asking directly on sites that are designed to put together people looking for contract programmers. Are you asking any more than you did here:

It's not safer than C++, it's exactly the same as C++

This is so stupid. Delphi and C++ are exactly the same in this regard.

In 2147 people will still be suggesting setting DoubleBuffered true to solve flicker problems rather than fixing the actual problem

Title bar panel is effectively VCL styles because theres no api for that, I think. So you probably just have to suck it up.

Late information boo

You should report these as bugs to Embarcadero, but unfortunately they've been unable to provide a mechanism for reporting bugs for last past few months.

I guess ARC per-se wasn't the big problem, it was more the attempt to support ARC compilers and non-ARC compilers with the same codebases??

Yes.

Wrong. Setting a dynamic array to nil is identical to setting length to 0 and identical to passing it to Finalize.

That doesn't help if you have multiple variables that refer to the same instance which I guess is a more likely scenario for double free.

This sounds completely broken. What if the file starts with the sentinel value that indicates that you have a utf8 payload. Why aren't you passing a separate header, and then the payload? And why are you passing utf16 at all. Isn't that just expensive. And if you must pass around utf16 please tell me that you are handling byte order correctly.

What's pretty astonishing is that the NSA thinks that Delphi is memory safe! See White House urges developers to avoid C and C++, use 'memory-safe' programming languages | Tom's Hardware (tomshardware.com) I guess the NSA don't know anything about Delphi. obj := TObject.Create; obj.Free; obj.Free; Take that, NSA!

Just let me know what you can do with C++ that you can't do with Delphi, in terms of safety

No it's not. Not really the point if a government agency will only accept work using tools that meet certain criterion. You can either follow the specification and have a chance of getting the work. Or argue about the specification and be completely ignored. That's just reality.