Stefan Glienke

I recommend SampingProfiler which simply works with either map file or td32 info in the exe. If you use the map2pdb Tool that Cristian linked you can use Intel VTune or uProf

I am absolutely putting my bet on this. The second issue after that will most likely be a non-cache-friendly access pattern. But you don't have to guess - run the code under a profiler and it will tell you the slow parts.

Wait for a compiler fix? 🥁

Just to make sure: this offset depends on how many fields your object has and how many interfaces it implements - the IMT slots always follow after the fields. For more info take a look into "Delphi in a nutshell"

Looks like a compiler defect - when changing this declaration: TOnMyIntfItemSelected<T: IMyIntfItem> = procedure(AItem: IMyIntfItem) of object; the code for TMyIntfItemA<T>.Select looks like this: List.Intf.pas.82: begin 007083E4 53 push ebx List.Intf.pas.83: if Assigned(FOnItemSelected) then 007083E5 6683781200 cmp word ptr [eax+$12],$00 007083EA 7411 jz $007083fd List.Intf.pas.84: FOnItemSelected(Self); 007083EC 8BD0 mov edx,eax 007083EE 85D2 test edx,edx 007083F0 7403 jz $007083f5 007083F2 83EAE8 sub edx,-$18 // this is where it turns Self into an IMyIntfItem, $18 is the offset where the interface method table pointer sits inside the object 007083F5 8BD8 mov ebx,eax 007083F7 8B4314 mov eax,[ebx+$14] 007083FA FF5310 call dword ptr [ebx+$10] List.Intf.pas.85: end; 007083FD 5B pop ebx 007083FE C3 ret but when it has the generic T parameter it looks like this: List.Intf.pas.82: begin 007083E4 53 push ebx List.Intf.pas.83: if Assigned(FOnItemSelected) then 007083E5 6683781200 cmp word ptr [eax+$12],$00 007083EA 740A jz $007083f6 List.Intf.pas.84: FOnItemSelected(Self); 007083EC 8BD8 mov ebx,eax 007083EE 8BD0 mov edx,eax // here it simply passes Self 007083F0 8B4314 mov eax,[ebx+$14] 007083F3 FF5310 call dword ptr [ebx+$10] List.Intf.pas.85: end; 007083F6 5B pop ebx 007083F7 C3 ret To explain this a bit more: when putting an interface type as generic type constraint this means for the compiler that the type you put for the generic type argument not only has to be that interface type but also that it can be a class that implements this interface. TMyIntfItemA<T> does this and thus satisfies the compiler when passing it to the argument of that event handler. However, inside the event handler, it is being treated as an interface and due to the lacking const parameter the compiler inserted an IntfAddRef call which blows up as the parameter that was passed was not really an interface reference but an object reference. Putting the const parameter makes it blow up a bit later though, namely when accessing Caption.

If you don't want instances, then don't make it a class - this ain't Java.

The question is this: do you want to get a wide adoption rate of something you've built or do you want to get two and a half coffees paid. As for how the console is done: Visual Studio Code simply communicates via stdin/stdout/stderr - see https://vscode.readthedocs.io/en/latest/editor/integrated-terminal/

Working on some better integration and result format that can be consumed by state of the art tooling such as https://github.com/danielpalme/ReportGenerator or https://github.com/marketplace/codecov but thats a side project that I don't spend much time on. Also still fighting some spurious crashes with DelphiCodeCoverage that result from it putting its breakpoints where it really should not (I suspect some incorrect debug information from the map file).

This issue is as old as generics are: https://quality.embarcadero.com/browse/RSP-10506

If your experiments are not just for educational purposes try out Spring - the container can do exactly that.

IMO the only true way to do this in pascal is as they done in Oxygene - see "if expressions": https://docs.elementscompiler.com/Oxygene/Delphi/NewFeatures/

I don't know what you mean 😇

Not quite - this is the null coalescing operator ?: is a special version of the conditional operator - it is short for "if <expr> is not null then give <expr> else give <something_else>" Null propagation operator ?. is a special member access operator - short for "if <expr> is not null then access <expr>.<some_member> else do nothing or return null" Given that Delphi does not have a conditional operator I would assume that even though we might get language support for nullable types (reference types fall into that category) we don't get the null coalescing operator but chances are that we get a null propagation operator - but that is just me assuming things.

You are most likely referring to the null propagation operator because there are plenty of nullable type implementations around.

If you are a seasoned Delphi developer you know that new features are not usable for like half a decade or so...

Code that originated in a Version before 2009

If you have a bad compiler that puts cold code into the middle of your hot loop where performance really matters instead of restructuring the code you need goto.

And you indeed refactored it into the only sane form I can think of! Might have moved the Result := False into that final else though because it's only needed then. And could have replaced the softcast with a hardcast because you already did the is check.

Certainly but that would change the behavior - currently if the class is found it exits, regardless. With a giant if and/or statement it would continue to evaluate the is checks.

We know they never do that but rather hope they be ready when they ship which also as we know it not the case either.

Here are some more: Wrong codegen: https://quality.embarcadero.com/browse/RSP-34539 Bogus error: https://quality.embarcadero.com/browse/RSP-34540 Bogus operator calls: https://quality.embarcadero.com/browse/RSP-34541

Apart from the names of the labels its actually not that terrible tbh - certainly better than repeating the same code over and over in every check.

Here is some code that I recently wrote that looks stupid but indeed is clever because the compiler is stupid: if P = nil then Exit(Boolean(P)); P is of type Pointer and it ensured that it's in the same register that the result is being returned so in case it's nil there is nothing to do (if you would write Exit(False) the compiler would insert extra instruction to actually make the register zero (which it already is)

No, it's just shorter than writing: var LKeepProcessing: Boolean; begin repeat LKeepProcessing := ProcessMessage(Msg); until not LKeepProcessing; end;

Wrong