David Heffernan

On 8/9/2024 at 9:31 AM, Vincent Parrett said:

I don't see the source to any of the dll's in those repos. I get that you are using those projects to build the dll's, but the fact remains that they are black boxes - I cannot tell exactly what they do, what their provenance is and whether I can trust them. I'm not trying to dismiss your work as invalid, just pointing out that and open source project distributing dll's need to provide a way for them to be built, or they must come from a trusted source (and usually code signed).    

This point has been raised many times previously fwiw

5 hours ago, Kas Ob. said:

Another point, it will works for old and new CPU.

Except aligned is now slower on modern cpus because of the less efficient cache usage when there is padding. 

1 hour ago, Stefan Glienke said:

That would be true if dynamic array allocation would be done in a way that ensures that element [0] would be at a 16 byte aligned address, which is not the case

It is if you use a proper memory manager

57 minutes ago, Kas Ob. said:

Remove the packed and/or make sure it is padded to multiple of 4 bytes, meaning 20 bytes should be your minimum, you might see better a little performance right away

This was true once upon a time but is not true for modern x86-64 architectures. 

You've spent more time posting here than you would ever save from this feature existing

45 minutes ago, PeterPanettone said:

Exactly. This is another reason to show the executable size after success and duration information—both for the debug and release build configurations.

But it doesn't change from one build to the next. Or is your problem that on Monday you know that the executable is 25mb but come Tuesday you've forgotten. Maybe you should get some post it notes. 

10 hours ago, PeterPanettone said:

For example, it could matter whether the executable size is 10 MB or over 100 MB.

So check the size in explorer. Not like you need to do this repeatedly. Are you having trouble using explorer? 

9 hours ago, Remy Lebeau said:

Really?

http://docwiki.embarcadero.com/RADStudio/en/Anonymous_Methods_in_Delphi

Yeah, I couldn't believe that anon methods arrived way back in Delphi 2009. I thought they were a much younger feature!! 

On 7/27/2024 at 6:30 PM, Remy Lebeau said:

Delphi introduced anonymous methods in 2009

What specific feature are you talking about here? 

Doesn't seem very useful to me. I wouldn't prioritise this. 

I don't know why you aren't facing up to the reality that you need to write some C++ code. 

You can't declare this structure in Delphi because it uses the STL type std::vector. 

6 hours ago, Markus Kinzler said:

VCL. CLX is long dead. Was (first) attempt of an cross platform solution. CLX was also used in Kylix (Delphi for Linux) being discontinued a long time ago. 

Delphi 7 is also long dead. 

Why do you need a smaller exe? 

Consider sharing a program that behaves this way 

12 hours ago, Der schöne Günther said:

In cases like this, I really love code editors and environments that can tell me right away to what type something infers by just tapping Ctrl+Alt...

 

Code editors telling you stuff is great but the bigger problem is the missing functionality at the fundamental language level. 

Classic delphi type ambiguity consequence

The scenarios I'm thinking of are numerical programming where the bottlenecks are migrated to math libs like openblas

2 hours ago, limelect said:

This is the same reason that the Basic language is gone. Interpreter.

For loads of scenarios the interpreter doesn't matter for performance. 

Personally I compile openblas and other libraries into dlls and link to them. Not least because the performance is obviously much better than code compiled by delphi. 

The naive answer to your question is that the object holds a dictionary whose key is the thread id. But it's far from clear that what you are planning will actually solve your problem. 

It's far more effective just to paste the function name into Google surely

This has always been possible. On win64 delphi compiler/linker has never respected the pdata exception tables so exceptions in the linked code have unpredictable results, for instance insta process terminate. Not sure if latest delphi fixes that. 

What directory would you have expected the files to be relative to? 

What I don't understand is why you didn't use the debugger or other debugging techniques to check what values were being passed in to the function. That's my idea for you.