Stefan Glienke

Changing that would raise some warnings in existing potentially defect code and some people don't want that Similar to being able to call non virtual class methods on instances

TL'DR 😛 Btw you can utilize the xmldoc for that - we are doing that for some of our classes and pump that into confluence. Does not need a single line of executable code or RTTI inside the to be documented to produce this. The only disadvantage this has is that implementation and what's in the xmldoc might differ.

Keep voting: https://quality.embarcadero.com/browse/RSP-13290 And given that the compiler already knows line numbers and the filepath it's working on for Assert it should be almost no effort to implement something like this as well: https://docs.microsoft.com/en-gb/dotnet/api/system.runtime.compilerservices.callermembernameattribute?view=netframework-4.7.1

Wrong approach - use a parser to generate doc out of some code. Agree on the nameof intrinsic though - but for other reasons.

That is because internally all RTTI through an TRttiContext is handled by a singleton instance and DUnitX itself is already using some TRttiContext. So the internal singleton already exists and your usage causes it to just create more objects that are then owned by that singleton instance which outlives the unit test because DUnitX keeps it alive. This general issue of cached objects created during unit tests that keep existing after the test ran and thus are considered leaks is known and LeakCheck has mechanisms for that. Add the following line into the dpr (needs LeakCheck and LeakCheck.Utils in the uses) TLeakCheck.InstanceIgnoredProc := IgnoreRttiObjects; For more details please see the Ignoring section in the LeakCheck readme In practice there are many more places in RTL and possibly custom code that use lazy creation/caching mechanism and are subject to such a leak detection approach (see InitializeLeakCheck in Spring.TestRunner.pas for some example of such madness if you are curious)

I am almost sure MMX Code Explorer can handle both - but @Uwe Raabe certainly knows better.

And they fully qualify every type -.-

We used SvCom for years but threw it away as we did not need any of those fancy features - using a simple TService with some additional code to let the service run as normal application that simply shows a small form with a start and stop button (useful for debugging)

The issue is not a memory leak but the use of an interface reference after the object behind it was destroyed already - see first post.

I read your post three times but I could not make any sense of it. What does "BPL are screwed" mean? And what does "bpl output" mean? The binary size of the bpl? So when using the class helper the binary is smaller than when not using it? What class helper? Provide more information and be less sketchy.

We keep all third party components in a separate git repository and are using Delphi Package Installer (slightly modified version) to build and install into the IDE on a new installation - also keeping all binaries in that repository (via git lfs). That enables going back and forth between versions without anything else than a branch or tag change of that repository (unless the vendor changes package structures - then it might require running the Delphi PI again) Initial installation or update is done by one developer on his machine using whatever setup or installation routine the vendor uses (I did most of the initial installation ones and try to do them with as little modifications as possible to make updating them a quick thing) and then putting them into the repository.

It handled a TList<TPoint> which I tested better than REST.Json - good. Unfortunately it's based on System.JSON which makes it a no go for me. What I like though is the architecture that enables encapsulating different collection types for serialization/deserialization - I just wished it would not require RTTI for builtin RTL collection types. From a quick look though extending serialization via own custom serializers is only possible for one specific PTypeInfo which makes this unusable for own generic types. For that the TCustomSerializer classes would need a CanHandle(AType: PTypeInfo) function or alike. This would also enable the currently hardcoded support for dataset, stream and RTL collections to be handled over this mechanism without having to hardcode them into TNeonSerializerJSON.WriteDataMember

Amazing amount of unittests

*puts sunglasses on and holds a pen up*

Yes, the need for those given that you just check for different cases on the same thing (typical if x is button then ... else if x is edit then ... else if x is ... cases) just comes from case of syntax element being of limited use only. Those horrors would not be worse than half a mile of if-then-else-if "ladders". Especially since in those you can easily hide some non conform pattern which can easily get unnoticed - for example checking x for 10 different types but then in some else if check y for something...) Language improvements of the category "syntax sugar" (i.e. something that could be done before but in a more convoluted way) should improve code readability by reducing the ceremony around the essence of what the code is supposed to do.

I think other languages also support this natively but here is the doc from C#.

The real issue I have with this style is that we have to write code like this in the first place because Delphi does not support pattern matching.

Yes, it is caused by loading the grid and then setting the viewtype to bandedtableview (I was referring to the BandedTableViewDemo Mainform) which then causes CreateView to be called which eventually runs into that shortcut thingy.

FWIW that exception also occurs when opening the MainForm in the IDE. And after that the IDE is trash and raises AV left and right Here is the relevant call stack: [50177955]{rtl260.bpl } System.Classes.TComponent.ValidateRename (Line 16888, "System.Classes.pas" + 4) + $3 [50178110]{rtl260.bpl } System.Classes.TComponent.SetName (Line 16979, "System.Classes.pas" + 7) + $3 [5006205D]{rtl260.bpl } System.@UStrAsg (Line 26353, "System.pas" + 19) + $0 [2C3075A3]{DeveloperMachines.FireDataGrid1.bpl} Firedatagrid.TFireGridViewBase + $4B [2C2919EE]{DeveloperMachines.FireDataGrid1.bpl} Firegridtableview.TFireGridTableView + $16 [2C2689C2]{DeveloperMachines.FireDataGrid1.bpl} Firegridbandedtableview.TFireGridBandedTableView + $16 [2C3014EB]{DeveloperMachines.FireDataGrid1.bpl} Firedatagrid.TFireCustomDataGrid.CreateView + $2F [2C301546]{DeveloperMachines.FireDataGrid1.bpl} Firedatagrid.TFireCustomDataGrid.SetViewType + $46 [50126816]{rtl260.bpl } System.TypInfo.SetOrdProp (Line 2878, "System.TypInfo.pas" + 37) + $4 [2100E952]{designide260.bpl} DesignEditors.TPropertyEditor.SetOrdValue (Line 840, "DesignEditors.pas" + 2) + $E It is caused by the call to TShortCutList.Add with s being 'Ctrl+''=''' which causes TextToShortCut return 0 Knowing that = is on the 0 key on a german keyboard it might make sense that this shortcut cant exist, technically it would either be Ctrl+0 or Ctrl+Shift+0 Just looked at a coworkers US layout keyboard to make sure - they have a '=' key. So you need to create those shortcuts differently.

"This also appears to affect OmiThreadLibrary" is very likely to be false - nothing in System.Threading is affecting the OTL at all - if the OTL reveals a similar behavior then it's most likely due to the solution and combination of parallel tasks itself. The PPL is a story of broken stuff since the first version. The issue in this particular report seems to occur because the threadpool spins up to 100 (by default, you can change that) threads as it sees that CPU usage is still low (not sure about the situation in the real code as that very likely does not use Sleep) and then is probably way more busy managing those than actually doing work.

To make this clear - there are - the "classic" compilers where everything is done by Embarcadero: Win32, Win64, OSX32, iOS Simulator - the "nextgen" compilers that use the LLVM architecture - that means they have to write the so called frontend which translates the code into LLVM IR - what they don't have to do themselves is the backends for all the various platforms and the linker. Now before anyone asks "well if they don't have to do the backend and can just use all the supported platforms from LLVM" - they still have to do all the system/platform specific code in the RTL for every platform.

At least its not "XE 10.3.4"

No, that would not release either - thats one of those bugs people keep reporting since ages and Embarcadero refuse to fix - I think @Dalija Prasnikar remembers the according QP entry. FWIW unless the comparer needs its own state you don't even need to create your own class, just pass a function(const left, right: T): Integer to TComparer<T>.Construct fwiw in Spring I added overloads to all methods taking IComparer<T> to also directly accept that - makes using them way more comfortable.

Mixing of object and interface references with a const interface param. Solution: declare the Comparer var as IComparer<TXTColumnPosition>

What the hell are you talking about? CLANG is the LLVM frontend for C++ - so basically what Embarcadero did for Delphi. The difference is that I don't know how many people are working on CLANG (including people from Apple, Microsoft, Google, ARM, Sony, Intel and AMD) instead of one and a half men for the Delphi one...