Stefan Glienke

It ever did? Not for code that I write and it does not completely format as I would like it to.

Nah, in fact I only use a fraction of what GExperts offers, I just cba to disable those that I don't need.

Use LeakCheck - there is even a blog post how to. Not having done anything on something that just works does not mean abandoned. If something does not work, let him know. FastMM is good to report memory leaks on an entire application run but not suited for unit tests memleak reporting - that is why LeakCheck was written plus having something that works cross platform.

Although I am a big fan of rtti and attributes I would choose the const array[enum] of x any day as its compact to write and compile time evaluated (i.e. error if someone introduces a new enum value and forgets to specify an array value for it).

Check the $RTTI directive in System.pas ... - also there is no this or that RTTI. Stuff from Rtti.pas just puts an easier to use layer ontop of the pointer stuff from typInfo.pas

Well, not if the method is private or protected

Yes, and I never stated otherwise - I just pointed out that you can patch virtual methods selectively by replacing them in the VMT. inherited calls would also still call into the old method with that approach. FWIW the approach you wrote for private virtual method works as well for a non virtual method. In fact the technique of hooking methods by placing a jmp has nothing to do with how the methods are being called. Especially for patching known code (i.e. RTL and alike) I rather write byte scanning code for finding the place I want to patch - yes such code has to be changed when you migrate to another version. But with that you can patch any code even if it's hidden deep within the private section of some classes or in the implementation part of a unit.

Either you know it by looking into the assembly for its call or look for the method pointer in the VMT.

{$APPTYPE CONSOLE} uses Windows; type TFoo = class procedure Bar; virtual; end; procedure TFoo.Bar; begin Writeln('broken'); end; procedure FixedBar(Self: TFoo); begin Writeln('fixed'); end; var f: TFoo; p: Pointer; n: UINT_PTR; begin {$POINTERMATH ON} p := @FixedBar; WriteProcessMemory(GetCurrentProcess, @PPointer(TFoo)[0], @p, SizeOf(Pointer), n); // 0 is the virtual index of the method to be replaced f := TFoo.Create; f.Bar; end. The virtual method index can also be found out programmatically.

When you patch a virtual method you don't need to patch it using the technique to place a jmp into the original code you can directly patch the address in the vmt slot. For that you just need to have the index of the virtual method.

If the code you posted is all the class constructor does it's pointless anyway as string variables don't have to be initialized to empty string.

Eh? No, if I in my host application code keep a TRttiContext and keep around some of those TRtti* instances retrieved they will be or contain dangling references. The removal of TRtti* instances of an unloaded module is triggered from TRttiPool.GetPackageList which only triggers if I go through any methods of TRttiPool which is an internal class accessed by TRttiContext. Been there, suffered from that

You only ever have to worry about dropping the TRttiContext when you unload modules such as dll and bpl during your application livetime from whom you needed rtti because then the type information from those modules is not removed and might still hang around possibly causing some issues.

I noticed that 10.2 noticably slows down due to the progress dialog. When compiling the exact same code in the commandline compiler or without the dialog. It even has been reported (https://quality.embarcadero.com/browse/RSP-22056) - not sure exactly what has been done since then as we won't upgrade from 10.1 for other reasons so my 10.2 and 10.3 installations don't see any huge projects.

Especially with DevExpress everything should be setup perfectly if you run their setup. You only end up recompiling their sources (and even if that should not affect linking time it adds a bunch to the compile time) if you manually put the directories with their sources into your library or project search path. Within the DevExpress installation directory there should be a Library folder (besides all the different ExpressWhatever folders for their different component suites). That Library folder contains all the dcus along with dfm and res files being produced by the compilation during their setup. That directory is being put into the library path. If anything else is the case then that is not ideal. P.S.: If you don't mind and are able to send me the map file of your application and I can quickly run that through some tool I wrote to peek if it suffers from heavy generic bloat.

No, it's not a good practice - write your classes in a way that you could do pure DI. If you do field injection that code can't run without a DI container or some other ways to do such injection. If you have too many ctor arguments you are suffering from so called constructor over-injection and there is a way to solve this: refactor your code and respect the single responsibility principle - see https://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/ Always think of a DI container as something like an automated assembling plant - all the screws and pieces that are put together there by robots don't know of the assembling plant. You can as well grab a screwdriver or some other tool yourself and put the pieces together manually with a lot of work and sweat but it's possible.

iirc circular units should affect the compiling but not the linking phase but I could be wrong. Extremely long linking phase for has been almost always a result of extensive use of generics (either through third party or your own) because the linker then has to look through all the dcus and remove identical ones (for example every unit that uses a TList<Integer> has the code for that entire class emitted into its dcu which the linker then has to read again fix up pointers and write that to the final binary which only contains one copy of TList<Integer> - but also one for TList<string>, TList<TPerson>, TList<TcxWhatever>, ....) Also sometimes very innocent looking generic APIs can cause a huge clusterf... of types being emitted into the dcus if one is not careful (I should know I wrote such APIs ^^) Look into the dcu output directly and tell us the size of all dcus combined - that should give a rough estimate if that is the cause or not

Personally I also find threads annoying that have multiple posts after each other from the same person. Possible solutions: - make posts editable for a reasonable amount of time so people don't have to multipost but can amend to their previous one - moderate and manually squash such posts into one

Next to the "unread content" one just like at the bottom I would say

Open the ico, remove all layers but 32x32, change the compression from bmp to png, save, done :) P.S. There you go favicon32.ico FWIW https://www.delphipraxis.net/favicon.ico has only 16x16

TestInsight does no magic in terms of "running tests" - it simply does the same as Run/Run without debugging. The client code then communicates via tcp/ip to the IDE to ask which tests are checked when you only want to run a limited selection and reports the results. However in the few times that I had to run tests on mobile myself the experience is not as smooth as with windows, linux or osx that all support some UI less application that simply starts, runs tests and closes. So I usually had some minimal FMX UI that showed the tests and had a run button or something.

Yes, DUnit (TestFramework.pas) compiles on all platforms that Delphi supports. I think many developers don't really understand the architecture of DUnit - its just a bunch of interfaces and classes using the observer pattern to listen to events like test started, test ended, test passed, test failed. That is what things like the DUnit GUI Runner or the TestInsight client listen to - well in a nutshell, the VCL GUI runner that we all know does a bit more like allowing to select individual tests and only run those but that all works through that interface. So you can implement that interface on any platform or UI or non UI framework you like. All the stuff that I added to make attributes with with DUnit is just ontop - like using enhanced RTTI to discover attributes on the test case methods, read their data and create testcases from that data. Usually it uses the classic rtti looking for published methods and produces test cases from those.

Make sure you are also pulling submodules - that's explained in the instructions linked by pyscripter for when you do it via cmd but when using some Git GUI it might not automatically do that. Otherwise it might use a jedi.inc from somewhere else (yes, other projects also use it)

https://stackoverflow.com/a/9006662/587106 Nowadays I suggest using https://bitbucket.org/sglienke/spring4d/src/master/Tests/Source/Spring.Testing.pas which adds the functionality mentioned in the SO answer but better than at that time and implemented in DSharp back then. Two features that I personally never needed so far but that DUnitX can do which DUnit can't do out of the box are: standalone testcase classes (i.e. not inheriting from TTestCase) and per fixture setup - can also be plugged onto DUnit. There might be other subtle features of DUnitX that I am not aware of but I am very sure that they could be added to DUnit either by inheriting or by modifying TestFramework.pas (the latter was one of the reasons Vincent rather rolled his own iirc)

Everything that DUnitX does can also be achieved using DUnit (with some minor adjustments or extensions) which then makes tests that don't use features that require Delphi2010+ such as attributes still work in older versions or existing DUnit tests can be kept and just improved using new features when moving to newer Delphi versions.