David Heffernan

You think wrong

Find out by debugging. Set a breakpoint on SetLastError. And inspect the call stack when it triggers.

The only error here is the code that calls GetLastError and uses the value at a time when its return value is meaningless. All you have to do is to stop doing that.

Yeah, should be using '%p' format string

Sure. But so what?

Amazing that they can't produce a 64 bit IDE....

Don't think of the problem as how to write the code effectively given the data structure. Think of the problem as choosing a combination of data structure and algorithm to solve your problem. In other words, ask about the underlying problem, and be prepared to consider a variety of other data structures, which in concert with the right algorithm might perform best.

8 times faster sounds amazing, if the only thing you ever do is call Pos on data that is already in the cache. I'll bet that for a lot of real world applications you wouldn't see any benefit.

Cross posted: https://stackoverflow.com/questions/61656924/smartpointers-do-not-work-well-with-a-generic-tobjectlist-in-delphi

If possible you should use side by side assemblies

Those links are to Stefan's clone. What about the author's repo?

Do you have any particular reason to believe that XE is a supported compiler?

Why do you feel that there might be a problem? The rules for identifiers are well documented. These all meet the rules.

No. That's wrong. In fact sin is quicker under x64 than under x86. Even though sin (and other trig) is implemented in hardware in the x87 unit, and in Pascal in x64 (because the SSE2 unit does not have built in trig).

The issue is that x64 trig functions are very slow for very large values. Nobody actually wants to know sin for 99999999/pi radians. Put in sensible values for the argument to sin and it looks more reasonable. For instance try using T:=Sin(i/99999999);

Essentially what the original post tells you is that these two types are distinct. Since they are declared in the rtl package, at least one of your modules is not linking to the rtl as a runtime package.

The best way is that you understand your design well in the first place. My reading of your various posts is that a lot of the time you are developing your code by following methodologies used like a recipe. I suspect that with a deeper understanding of why these methodologies were being used then you wouldn't find your code alien when you encounter it.

Impossible to know without benchmarking. Depends on what your application spends its time doing.

Mask floating point exceptions, probably

Another way to improve performance is to design the code to minimise heap allocations. The best way to optimise a block of code is not to bypass it.

It's pointless to say that one memory manager is n times faster than another because usage varies so much. One thing that is surely true is that different applications have different needs. I'm personally pretty sceptical that one single memory manager can perform optimally in a wide range of usage scenarios. Nothing wrong with choosing the MM that best fits each application.

Oh. This again. Surely your users can just make the the icon appear always if they want to. Perhaps they don't want to.....

There are lots of bugs in the IDE that could explain this. But this could equally be caused by bugs in design time packages or plugins that you have installed. It won't be caused by the code that you are compiling in the IDE.

I don't understand the problem. I think that if you want some input you'd need to make it more clear to us what your code is doing and how it fails to achieve your goals.

You could just ignore the error. Is it causing any trouble.