Stefan Glienke

TJsonTextReader calls Close during Destroy on its FReader and that as Dalija explained might still work on Windows because even though the object and its memory is not valid anymore it has not been reused yet. You can test this quite easily with this code: uses FastMM5, System.Classes, System.JSON.Readers; begin FastMM_EnterDebugMode; var LStringReader := TStringReader.Create(''); var LJsonTextReader := TJsonTextReader.Create(LStringReader); LStringReader.Free; LJsonTextReader.Free; end. And you get a nice "A virtual method was called on a freed object" exception resulting from the FReader.Close call in TJsonTextReader.Close

Why would LSPServer affect anything that dcc32/64 do?

Not tested for correctness but translating this C++ code into Delphi should be easy enough: https://de.wikipedia.org/wiki/Voronoi-Diagramm#Programmierung

The default string comparison is done via lexicographic order - what you need is natural sorting - you can achieve this by providing a custom comparer to TArray.Sort that handles that - on windows you can use https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-strcmplogicalw for that

GitLab is amazing and you can host on-premise - for some people including our company, this is important.

i7-12700 at work, i5-13600 at home

The fact that I mention a version number when resolving an issue does not imply that this version is already publicly available - in the future, I will use the words "will be fixed" to refer to a not yet released version. During my vacation, I stayed away from anything programming plus I got new hardware both at home and in the office and neither has all Delphi versions installed yet which are required to create a new setup.

https://www.regular-expressions.info/anchors.html

If stuff blows up with ASLR under 64bit then this is almost certainly because some code is calculating addresses wrong or unintentionally using 32bit data types where 64bit is needed which did not blow up without ASLR because it never had values higher than maxint. Often this can be caused by incorrect Winapi usage such as this

That's why you use things like madExcept or EurekaLog - even with ASLR enabled I get a proper call stack from an AV with madExcept.

Which has been a solved problem for quite some - it's called IntroSort - no language I know uses plain QuickSort as their default standard library sort these days. If not IntroSort they might use TimSort.

That's some weird implementation of a lower bound binary search tbh Not true - in a lower bound binary search you keep on binary searching until your range got down to 1 element - with a loop you turn O(log n) into O(n)

https://security.stackexchange.com/questions/18556/how-do-aslr-and-dep-work

The answer still is yes - your code actually mutated the stack - all proposed answers avoided that - some even avoided any allocation and mine even gave you a drop-in solution. The only question that could be answered with "No" would have been: Is there any solution to this problem where I don't have to write any code for?

Yes. If you wanted to know if there is any method that does that then you should have expressed your question more precisely. But hey let's ask a vague question and then offend anyone providing help by ignoring them.

type TMyStack<T> = class(TStack<T>) function Peek(indexFromTop: Integer): T; overload; inline; end; {$IF RTLVersion < 33} type TStackAccess<T> = class(TEnumerable<T>) FItems: TArray<T>; property List: TArray<T> read FItems; end; {$IFEND} function TMyStack<T>.Peek(indexFromTop: Integer): T; begin Result := {$IF RTLVersion < 33}TStackAccess<T>(Self).{$IFEND}List[Count - indexFromTop - 1]; end;

Spring4D Events are just multicast events (like your regular OnClick but with possibly multiple handlers) - an event bus is more.

Upper and lower bound - look it up

Certainly not like that because this will not consider a value next to the potential find that is a closer match - when the list has a different count of elements the result could be different.

And what exact benefit would a non-ref counted interface have? Once you pass down some you lose any control over its lifetime.

With the current memory model that would be a complete disaster. The main appeal of using interfaces when doing some DI architecture is the ref counting. And the mantra "program to an interface, not an implementation" is factually wrong: read https://blog.ploeh.dk/2010/12/02/Interfacesarenotabstractions/

The difference in performance is clear - accessing a dynamic array which is a field inside the class is two indirections while accessing a static array which is a field inside the class is only one indirection. If you inspect the generated assembly code you will see that every access to the dynamic array has more instructions. This is the case every time you have repeated access to a field inside a method because the compiler does not store it away as if it was a local variable and then directly reads it but basically does Self.Table every time. For this exact reason I have explicitly written code that first reads the dynamic array into a local pointer variable (to avoid the extra reference counting) and then operate on that one via hardcast back to dynamic array (or via pointermath). That way the compiler could keep that in a register and directly index into it rather than dereferencing Self every time to read that dynamic array. To try out, add this code to your Button1Click: {$POINTERMATH ON} Table: ^DWord; {$POINTERMATH OFF} begin SetLength(Self.Table, NbPrime); Table := @Self.Table[0]; Now the code accesses the local Table variable which most likely is stored in a register.

If you are using XE2 as in your profile you could be affected by this: https://quality.embarcadero.com/browse/RSP-27375 And as David mentions depending on what is inside the try the compiler easily throws any register usage overboard and operates via stack.

https://quality.embarcadero.com/browse/RSP-23096

That Poker Benchmark is completely pointless as it has almost zero memory allocations - the majority of CPU time is spent sorting cards and stuff.