Stefan Glienke

TGUID contains this field: D4: array[0..7] of Byte; which does not emit typeinfo for its type You can see this with the following code: uses System.Rtti; var ctx: TRttiContext; begin var t := ctx.GetType(TypeInfo(TGUID)); for var f in t.GetFields do Writeln(f.ToString); readln; end. The issue (not specifically for TGUID) is reported: https://quality.embarcadero.com/browse/RSP-27329 Now even if the RTTI would be available it would serialize TGUID in some format that is most likely not desired. However TGUID <-> string serialization should be supported out of the box imo.

The problem within the global begin/end block is special - usually, inline variables are shown in the debugger but with the limitation that the compiler does not emit so-called live-range data for them which the debugger can use to know the locations they are valid for. For example having two nested variables of the same name causes issues with properly inspecting them because the debugger always shows the value of the first (which causes wrong data to be shown) which also has been reported multiple times.

No, just pray the issue gets fixed in your lifetime

No, because the parameterless TObjectList<T> constructor sets OwnsObjects to True. And that is nothing new but also already was the case in the old TObjectList from Contnrs.pas I am glad I can use Spring4D and have several flavors of multimaps at my disposal

It is from my own experience and analyzing generated code in several different scenarios. I have seen the inliner generating like x times more instructions including ridiculous amounts of mov instructions to and from the stack just to inline a harmless little function which it could way better if the inliner and the register allocator would not have been absolute trash. Plus there are "funny" little issues like this: https://quality.embarcadero.com/browse/RSP-30930 Here is an example where inlining creates some ridiculous amount of instructions: https://quality.embarcadero.com/browse/RSP-31720 (which is not caused by auto but the fact that the getter is being marked as inline)

I would never ever turn it to AUTO because that causes the compiler to inline every function that has a size of 32 bytes or less. The inliner of the Delphi compiler is really bad and while one might think that inlining code usually makes stuff better/faster that is not the case and usually (decent) library developers know where to put inline and where not to put inline.

I assumed it would be obvious from the uses

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