On Fri, Aug 2, 2013 at 1:07 PM, Sven Barth <pascaldra...@googlemail.com> wrote: > On 02.08.2013 17:50, Flávio Etrusco wrote: >> >> On Fri, Aug 2, 2013 at 12:34 PM, Sven Barth <pascaldra...@googlemail.com> >> wrote: >>> >>> On 02.08.2013 17:01, Mattias Gaertner wrote: >>>> >>>> >>>> On Fri, 02 Aug 2013 13:18:53 +0200 >>>> Sven Barth <pascaldra...@googlemail.com> wrote: >> >> >> (...) >> >>>> What about code size? >>> >>> >>> >>> The code size for one unit is the same as if you had (in that example) >>> declared a variant of "IsIn" for each "LongInt" and "String". So for each >>> "IsIn<T>" specialization with different types new code is generated if it >>> does not yet exist in that unit. This means that if you call >>> "IsIn<LongInt>" >>> in different units you'll have a "IsIn<LongInt>" implementation in each >>> unit. This is the same as for generic types btw. >>> >>> Regards, >>> Sven >> >> >> >> And the same (problem) in C++. Is there some proposal to mitigate the >> code duplication? Or the official position is that if the project is >> big enough to suffer from the bloat it should avoid itself the >> duplicate declarations? > > > The problem is that it's not really possible with the unit concept FPC uses. > If you want to share the code with other units the code needs to be callable > from the interface section, but when you are working in the implementation > section (where most specializations take place) you should not modify the > interface section anymore as this needs to trigger a recompilation of all > units that depend on that unit. This already leads to some hard to detect > bugs in context with inlining (which does exactly that, because the node > tree of the inline function is stored in the interface part of the PPU). The > type of interdependencies are for example a problem in FPC itself which > leads to strange compilation bugs (e.g. identifier not found, although it > exists, corrupted unit loadings, etc) if you do a normal compile (Ctrl+F9 in > Lazarus) after you changed something in the interface section of some heavy > used unit. These bugs of course need to fixed, but they are very hard to > reproduce in smaller setups... > > > Regards, > Sven
Thank you very much for the detailed explanation :) Best regards, Flávio _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
