santiago

I was able to figure out the correct download link (by looking at the first alpha download link. 🙂 The correct link is: https://download.dummzeuch.de/GExperts/1.3.19_2021-11-26_for_Delphi11-Patch2/GXRS11_1.3.19_ALPHA2_experimental-twm_2021-11-26.exe

Wow Remy! Thank you for such a detailed answer. 🙂 It is now crystal clear to me. I never use those types of casts with interfaced objects, but since I had seen them since day 1 when I got started with Delphi I assumed it was legit. And oddly enough they have been working fine for many years!! That is why I got so confused when I removed a redundant interface declaration and suddenly it stopped working. In the meantime I have already replaced several of the unsafe casts with safe casts.

Great! Thank you! Understood now. 🙂 This means that we need to change all the locations in our legacy code that perform such casts. I am just surprised as to why we have not had any problems before that. They have been in there for ages.... And some are called rather frequently.

Am sorry David, but I don't quite follow. Variable Obj is an instance of TMyClass and is declared as IInterface. TMyClass does implement IMyInterface. So it should be a valid cast. However when we call a method the access violation occurs. We have some legacy source code that does such things: IWhatever(SomeVariable).AMethod; It has been running fine for years. The other day it broke because I removed an Interface declaration from a derived class, since the interface was already implemented in a base class. So basically we had: TDerivedClass = class(TBaseClass, ISomeInterface1, ISomeInterface2, ISomeInterface3) and I changed it to: TDerivedClass = class(TBaseClass, ISomeInterface2) because TBaseClass already implements ISomeInterface1 and ISomeInterface3. And suddenly ISomeInterface1(AVariable).SomeMethod; resulted in an access violation. Thank you!

Thank you Kas. What do you mean exactly by "managed types"? If I understand correctly it is not safe to use such casts with TInterfacedObjects that implement many interfaces. What puzzles me though is that in our source code we have several locations where we do precisely that: IWhatever(SomeVariable).AMethod; This has been used in our software for many years, way before I got started with Delphi. The other day I removed a redundant interface declaration from a derived class. The interface was already listed and implemented in a base class. And all of the sudden some tests started failing. The reason was that such unsafe casts which had been working properly so far, no longer did. Am I correct in saying that we must always use Supports or as when dealing with TInterfacedObjects and unsafe casts should be avoided unless you really know what you are doing?

Hi there, I have the following interface and two simple classes. A base class and a derived class (super class). IMyInterface = interface ['{34408757-240F-4B63-A1CA-4B1FC3BF5072}'] procedure DoesNothing; end; TMyBaseClass = class(TInterfacedObject, IMyInterface) procedure DoesNothing; end; TMyClass = class(TMyBaseClass) end; and wrote the following test method. I would like to understand why we get the EAccessViolation with the hard (unsafe) cast. procedure TMyDebugUnitTestCase.Test_MyTest1; var MyObj1: IMyInterface; MyObj2: IMyInterface; MyObj3: IMyInterface; Obj: IInterface; begin Obj := TMyClass.Create; CheckTrue(Supports(Obj, IMyInterface, MyObj1)); MyObj1.DoesNothing; MyObj2 := Obj as IMyInterface; CheckNotNull(MyObj2); MyObj2.DoesNothing; MyObj3 := IMyInterface(Obj); CheckNotNull(MyObj3); MyObj3.DoesNothing; // EAccessViolation -> Access violation at address 00000001 in module 'CoreTests.exe'. Read of address 00000001 end; The problem also happens if I declare the derived class as follows: TMyClass = class(TMyBaseClass, IMyInterface) end; Is it necessary to explicitly list interfaces already declared in base classes in the super class? To me this just seems redundant. Am I correct here? I have heard from other developers saying that this is necessary, but being unsure as to why, Thank you!

Marco, do you have an estimate when this patch will become available? I would like to give 10.4.1 another try. Currently we are still on 10.3.3.

I use 10.3.3 with IDE Fix Pack and have not had that issue to such an extent. It has happened though that Code Insight has stopped working. If I remember correctly it works after a while or just by restarting the IDE. These incidents have been very few and far between, so for me it has not been much of an issue. I will pay more attention next time it happens. But I do use 10.3.3 + IDE Fix Pack on a daily basis on a very big project.

I cleaned up one project (40K lines of code, ca. 80 units, depends on 21 projects). I cleared the 'Unit Scope Names' from the Project Options to be empty. I had to fix many compile errors (in 47 units) by using the full scoped name (e.g: System.SysUtils, instead of just SysUtils). Delphi Rio 10.3.3 (WITH IDEFixPack) Before the changes this project compiled in ca. 8 seconds After the changes it improved slightly to: ca. 7.7 seconds Delphi 10.4.1 Before the changes: ca. 11.5 seconds. After the changes: 8.7 seconds. Delphi Rio 10.3.3 (WITHOUT IDEFixPack) Before the changes: 18.1 seconds After the changes: 14.5 seconds Ideally you should always use the fully scoped names. I would have never had thought that this would have such an impact on compile time...

Now I follow you 🙂 This is very actually very interesting. This is how the 'Unit Scope Names' settings look for our projects. If I understand correctly, the fewer unit scopes that are defined here, the faster the project will compile. Correct? I am certain we don't need all those entries. I guess no one has ever looked into it until now. Anyhow, I will try to eliminate the need for using Unit Scope Names.

This is how it looks like for me (Delphi Rio 10.3.3). Unit Aliases is something I have never needed to use so far.

This is how I disabled it (Might be wrong, as I did not find any documentation on this): SET IDEFixPack.DisabledPackages=Compiler.UnitScopeNames In our case it had no impact.

I did some quick tests with our project. 2.1 mio lines of code. (1 group project, consisting of 24 projects). 10.3.3 =1.08 min Disabling the UnitFindByAlias patch, makes it 20 seconds slower. This is similar to the build time using 10.4.1 In the Delphi Compiler Options, UnitAlias is empty.

How do you activate/deactivate individual patches? -- EDIT -- nevermind. I see you attached a screenshot on how to do it. Thank you!

Lets say over 100 Units.