[fpc-devel] Little feature teaser
flavio.etrusco at gmail.com
Fri Aug 2 18:11:24 CEST 2013
On Fri, Aug 2, 2013 at 1:07 PM, Sven Barth <pascaldragon at googlemail.com> wrote:
> On 02.08.2013 17:50, Flávio Etrusco wrote:
>> On Fri, Aug 2, 2013 at 12:34 PM, Sven Barth <pascaldragon at googlemail.com>
>>> On 02.08.2013 17:01, Mattias Gaertner wrote:
>>>> On Fri, 02 Aug 2013 13:18:53 +0200
>>>> Sven Barth <pascaldragon at 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
>>> in different units you'll have a "IsIn<LongInt>" implementation in each
>>> unit. This is the same as for generic types btw.
>> 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...
Thank you very much for the detailed explanation :)
More information about the fpc-devel