Stefan Glienke

The issue is not static typing but the ridiculous amount of ceremony required.

I already sent feedback to Google - nothing else I can do about it.

And there I am, still hoping for that day to come

Mostly the language war that some people made out of that. The accepted Delphi solution even with inlining is like half as fast as it could be if you know the quirks of the Delphi compiler. Since the process of what was accepted and not was apples and bananas (such as insisting to create instances for Delphi/Pascal but use stack allocated objects in C++ that don't require a heap allocation) I did not bother with providing any version. Plus the non-availability of a docker image with Delphi to run the tests.

Which PrimeSieve implementation do you use? There has been quite a fuss around that last year after the Youtube Video series by Dave Plummer.

Usually it is left to right like in C# which is one of the few languages that has very little UB - https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#12623-run-time-evaluation-of-argument-lists

It does not - it simply does not contain that version in some Combobox. SamplingProfiler (both 32 and 64) works with the latest Delphi versions just fine. For VTune - I am so happy they finally added Flamegraph to the Hotspot profiler.

While writing the code I figured that for the issue to show it does not need anything that really inherits from the type the generic is constrained on because the issue is within the generic itself. I just did not remove the Child declaration. It's just there to show that you might instantiate the generic type with anything inheriting from Base that satisfies the constraint. If I had to guess I would say that when inheriting Y from X the compiler does not put the actual T into the generic type parameter but just the type it is constrained on or something - at least for the parameter checking.

The supports is misleading. The generic type parameter I is contrained to be of IBaseBroker and thus ABroker can directly be assigned to BaseBroker (as a side note in that case you would not get an AV because then the same interface pointer that points to the IMT for IFooBroker would be passed down satisfying the later call to GetMsg). However the bug is that the inherited Create call which has I as parameter (which is in this case IFooBroker) accepts the base type that it was constrained on. Here is the issue a bit more condensed - and showing it does not only apply to interfaces: type Base = class end; Child = class(Base) end; X<T: Base> = class procedure Test(obj: T); end; Y<T: Base> = class(X<T>) procedure Test(obj: T); end; procedure X<T>.Test(obj: T); begin end; procedure Y<T>.Test(obj: T); var b: Base; begin b := obj; // obj IS a Base because T is constrained to be a Base inherited Test(b); // this MUST NOT compile because the parameter is T and Base is not a T end;

I wonder where that chart is from because the numbers of LLVM and GCC are clearly bogus

It's a UI thing so I never considered thread safety. Especially as I just wrote it as a prototype.

Someone should have invited David Millington or the dev at Embarcadero that is now responsible for those plugins to the Delphi 11 beta so they could have worked on those plugins at the time when many other IDE plugin devs did. /s

No, he sounds tired of people that fight against expressiveness for the sake of complexity. Funny, around that time I was like "Dayum!" remembering how much code I had to write in Delphi for redblack-tree rotation.

The issue with the CMR implementation is that the theoretical benefit of having less overhead is eliminated by the amount of garbage the compiler produces in some scenarios. Version 2 in the Grijjy article works like unique_ptr in C++ but without the important feature that you cannot assign one unique_ptr to another one because well its unique (this is because the ref count is inside it and not shared across multiple references) as in Version 3 in the Grijjy article where the ref count is shared but requires a heap allocation - Version 4 does not because it uses the monitor field but that is a hack that might break if you use it on something that uses TMonitor. I have done some performance tests and because the Spring4d implementation does not use a full blown object behind the interface but a handcrafted IMT the overhead is less.

If you mean the TArray class with the Sort methods and so on then it's System.Generics.Collections. TArray<T> in System is not a class but a dynamic array declaration.

Whatever... all types with TypeKind = tkFloat 🤷‍♂️

I don't know what you mean 😉 Yes, I meant decimal type

Bug and already reported - all types of typekind = tkFloat getting inferred as Extended - which then causes followup errors: https://quality.embarcadero.com/browse/RSP-25799 https://quality.embarcadero.com/browse/RSP-31289

No On a more serious note: This would require the compiler to know that the repeated call is to a pure function - GCC for example has such an optimization, clang on the other hand as far as I could find (I did not spend much time) does not.

The benefit is having individual test cases generated which can be executed individually - if you ever messed with conditional breakpoints or pass counters to stop at exactly those args that cause the failure you know what I mean.

If you type "how to unit test and what to test" into google the first page lists a plethora of good articles on the subject

Because hot reload is a modern part of the R in RAD. Stopping, recompiling and getting to the point where you were before the change would be completely unnecessary. Game devs using UE or similar tools have been using this for quite a while.

They cannot even build a stable debugger - how could they ever achieve this.

Hence my word of warning You might not want to suffer the same amount of pain as I do

This has nothing to do with CharInSet per se but the fact that the Win64 compiler obviously is doing a poor job inlining it. Win32 code looks like this (i modified it slightly using a loop var rather than increasing the PChar): CharInSet.dpr.18: while not CharInSet(cp[i], [#0, #13, #10]) do 004C999C 0FB71446 movzx edx,[esi+eax*2] 004C99A0 6685D2 test dx,dx 004C99A3 740C jz $004c99b1 004C99A5 6683EA0A sub dx,$0a 004C99A9 7406 jz $004c99b1 004C99AB 6683EA03 sub dx,$03 004C99AF 75EA jnz $004c999b CharInSet.dpr.48: while not (cp[i] in [#0, #13, #10]) do 004C9B5B 0FB70C42 movzx ecx,[edx+eax*2] 004C9B5F 6685C9 test cx,cx 004C9B62 740C jz $004c9b70 004C9B64 6683E90A sub cx,$0a 004C9B68 7406 jz $004c9b70 004C9B6A 6683E903 sub cx,$03 004C9B6E 75EA jnz $004c9b5a Caution: if you go down that road you might feel the urge to rewrite half (if not more) of your code that is using RTL functions because the Win64 compiler does some terrible job on many of them. Edit: reported codegen issue: https://quality.embarcadero.com/browse/RSP-35981