Am 30.01.2018 um 15:07 schrieb Maciej Izak: > 2018-01-30 14:40 GMT+01:00 Marco van de Voort <mar...@stack.nl > <mailto:mar...@stack.nl>>: > > Have you tested this with large methods? The trouble is we only get > reports/code from people for whom the hack succeeded, not from ones that > tried and failed. > > I can remember from one of the bugreports or mail threads about very large > procedure bodies (where FPC hit virtual register numbers) that Delphi > starts > to deallocate temps earlier depending on procedure size and maybe used > language constructs. (number of structured temps?) That was mostly > strings, > but might also go for interfaces. I can also imagine that one would like > to disable this in case recursion is detected. > > > Yes I am aware of this. In the case of interfaces for large methods all seems > works as presented for > simple example. I was not able to reproduce this problem for interfaces. > > > > Seems like the SCOPEDINTERFACEDESTROY mode-switch is necessary. > > No, one could also simply fix the relevant code. > > > I am not the fan of SCOPEDINTERFACEDESTROY. My first impression about this > was : WTF. In some cases > is almost impossible to fix large legacy (and often wrong) code base. > > > > question is: would we like to enabling this for all Delphi modes? > > Everything that needs this is essentially feature abuse. I would not > enable > it by default > > > +1 . Anyway I am still considering : commit or not :P.
If is implemented, it needs to be clearly documented how it works. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
