David Heffernan

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.

I think that's about right. The issue you were facing though is 2 rather than 1. The type that matters here is the handle type. LPPPLFHANDLE is a pointer to a handle. You were managing the pointer to correctly, but your handle was wrong. You could actually declare your function like this: // an out param function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; out handle: PPLFHANDLE): LONG; stdcall; // or a var param function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; var handle: PPLFHANDLE): LONG; stdcall; Either of these would work. I show these to give a view on conceptually what that handle param is doing. I usually prefer having a literal header translation so the version in my previous message is how I would do it. And for some function you want to be able to pass nil to indicate that you don't need the function to return a handle. In this case I'm pretty sure you'd never want to do that, you always want the handle, and so the out param version would be a reasonable translation. Hope that helps!

The key here is that PPLFHANDLE is 32 bits in a 32 bit process and 64 bits in a 64 bit process. So you need a type that has the same property. For instance any pointer, or NativeInt or NativeUInt. Now, in this case it seems that the expedient thing to do is to declare PPLFHANDLE as HGLOBAL. And in the Delphi winapi units HGLOBAL will be declared as a type that switches size based on process bitness. Actually it's NativeUInt but that's actually a detail you don't really need to know. Although it's nice to know it and help confirm the understanding! So I would do this: type PPLFHANDLE = HGLOBAL; LPPPLFHANDLE = ^PPLFHANDLE; function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; handle: LPPPLFHANDLE): LONG; stdcall; Here I am using the same types as the header file. I generally think that it's preferable to keep an API translation as close to the original as possible. The header file is a bit odd in the way it defines these types: #ifndef PPLFHANDLE #ifdef _WIN64 #define PPLFHANDLE HGLOBAL #else #define PPLFHANDLE LONG #endif #endif #ifndef LPPPLFHANDLE #ifdef _WIN64 #define LPPPLFHANDLE HGLOBAL * #else #define LPPPLFHANDLE LPLONG #endif #endif It looks like an earlier version wrongly declared PPLFHANDLE as LONG and then they've kept that mistake as they catered for 64 bit. This header code should really look like this: #ifndef PPLFHANDLE #define PPLFHANDLE HGLOBAL #endif #ifndef LPPPLFHANDLE #define LPPPLFHANDLE PPLFHANDLE * #endif

That's also wrong.

No, you can have a single definition. You just need to get it right. I doubt that. Where is the header file? Or can you show enough of it so that we can see the declaration of LPPPPLFHANDLE?

There is no such incompatibility. It's just 64 to 32 bit value truncation caused by defective code.

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.