[fpc-devel] Little feature teaser

[Sven Barth]

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> wrote:
>> 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 "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