Hello Jonas, Sunday, April 5, 2009, 2:09:33 PM, you wrote:
JM> If you have a class hierarchy tbase->tderived1->tderived2 with a JM> virtual method called "vmethod", and nowhere in the program there is a JM> call to vmethod, then it is unused. Or if it is only called using JM> tderived2 instances, then if the linker does not find any direct JM> references to tderived1.vmethod or tbase.vmethod (e.g., via JM> "inherited" calls from tderived2 methods), it knows that the VMT JM> entries for vmethod in tderived1 and tbase can be set to nil. In fact I was thinking in something like this: TCustomFoo=class(TObject); TDerivedFoo=class(TCustomFoo) procedure Myprocedure(); virtual; end; TDeDerivedFoo=class(TDerivedFoo) procedure MyProcedure(); override; end; And in the code: var MyObj: TCustomFoo; begin MyObj:=TDeDerivedFoo.Create(); TDerivedFoo(MyObj).Myprocedure(); end; Something like this could kill the dead code detection ? A simple yes/no is enoght :) >> JM> that produces an error if you try to link a unit compiled with the >> JM> option using the external linker), but that hasn't been done yet. >> >> Just for curiosity which is the parameter set ? JM> Compile the compiler with -dvtentry. It's not been tested for a while JM> though, as far as I know. I'll play with it just for fun... JM> I also made a mistake in my previous explanation: currently, the WPO JM> does not yet perform the optimization the -dvtentry does. -dvtentry JM> looks at which VMT entries of a class hierarchy are never accessed, JM> and replaces those by nil. As a result, if those methods are not JM> referred directly, then they can be removed by the linker. I understand it in that way already. JM> The WPO looks at which class types can be instantiated in the program JM> and at the inheritance tree, and based on this determines which [...] JM> referenced directly, then they can be removed by the linker (and the JM> ones that are referenced can be turned into normal function calls). More or less I understand the WPO way of work. Thank you again. -- Best regards, JoshyFun _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal