David Heffernan

Split views which other IDEs have had for years. And bug fixes. But still no way to report bugs. Does this seem like value for money to anybody?

Unlucky for you. I've so far never encountered such a problem. The type of thing that forces me to debug 64 bit is when it's my DLL hosted in a 64 bit process, and I don't have a 32 bit version of the host.

I think all in all, it's clear that the current in-process design is the right one

How are you going to have the components paint themselves on the design surface?

Win64 debugger is known to be terrible. Perhaps slightly less so with more recent versions. I always debug 32 bit if at all possible. But sometimes you have a scenario where that's not possible. Unlucky if you do.

I can imagine this working fine for non visual components but what about components that paint themselves on the design surface? Cross process window hierarchies are basically untenable.

Automatic stack allocation is faster than all heap allocators, and has no thread contention. And Delphi's current heap allocator is known not to be scalable. I've measured this in a real world setting. Avoiding heap allocations when converting numbers (integer and real) to text makes a huge performance difference when creating files, e.g. XML, JSON, YAML. Even when single threaded. When multi-threading the impact is even greater, if using the default heap allocator. I personally use isolated per thread heaps to reduce contention. This doesn't eliminate it because every allocation/deallocation that requires a call to VirtualAlloc and friends has contention.

I mean, how hard could it be????

You suspect encoding is an issue but I can't see in your post any discussion of encoding.

Sometimes you do compare up to tolerance. Sometimes that's the right way to do it. But you need to know how to choose the tolerance. And it's definitely wrong to say that one must never compare exactly. Sometimes you can. Although delphi rtl works against you. For instance you'd hope to be able to convert floats to text, and back, and get the same value. In Delphi using the rtl functions this isn't always the case. Embarcadero have known this for more than a decade and not done anything yet. I just don't think they have the resources required to prioritise this given all their other commitments.

It depends on what you are comparing, what algorithms are involved etc.

Well, that's true. Lots of thread safety issues with how it handles floating point control status. But that's not that same as having a math lib.

I don't have a math lib that is publishable. I've never wanted to have or do such a thing. You must be mis-remembering.

I know how floating point math works, it's been what I've done for a living for the past 30 years. Using arbitrary epsilon values is not failsafe and relies on luck.

Floats can be compared for exact equality, in plenty of circumstances. The beginner mistake is to use some epsilon value without any sound rationale for it. Usually, and works pretty good, and for the majority of cases doesn't sound great with my numerical programming head on.

This entire approach of applying some arbitrary epsilon is rubbish. I can't imagine any scenarios where they'd be useful and I've only ever seen them used inappropriately.

The best way to deal with this is never to call any of these functions in the first place, they are all useless

We'd all like that. Prospects are not good for it happening.

There's all sorts of things that Delphi should allow as constants, but that's a long known area of significant weakness in the language.

No

Exactly!

These microbenchmarks for floating point typically are of quite limited use. I remember making a bunch of changes based on such benchmarks and then finding absolutely no impact in the actual program, presumably because the bottleneck was memory.

There's nothing to understand, the original statement from @DelphiUdIT is incorrect

You call this method I think, however that's done from Delphi CoreWebView2Profile.ClearBrowsingDataAsync Method (Microsoft.Web.WebView2.Core) | Microsoft Learn

Problem with doing this is that it will scale your window size also which is usually not what you want.