[fpc-devel] [Suggestion] Enumeration range-check intrinsic
Sven Barth
pascaldragon at googlemail.com
Tue Jul 16 11:28:10 CEST 2019
Ben Grasset <operator97 at gmail.com> schrieb am Mo., 15. Juli 2019, 23:48:
> On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel <
> fpc-devel at lists.freepascal.org> wrote:
>
>> That is exactly what is happening if you have a specialization in
>> multiple units that don't know about each other.
>>
>
> At what point are they being removed so that the executable is not
> comically large, then? Is it on the FPC side, or the linker side? Or a bit
> of both perhaps?
>
They are not removed. At least not in the way you think:
Declare a type" TTest = specialize TFPGList<LongInt>;" in two different
units (here ugentest1 and ugentest2) and then have the following program:
=== code begin ===
program tgentest;
{$mode objfpc}
uses
ugentest1, ugentest2;
begin
// TFPGList<>.Assign is a non-virtual method
Writeln(HexStr(@ugentest1.TTest.Assign));
Writeln(HexStr(@ugentest2.TTest.Assign));
end.
=== code end ===
The output will then be two different addresses, thus showing that the code
had been generated twice.
However the compiler/linker is good at leaving out unused code and in this
case only the two Assign specializations are kept as their addresses are
taken, everything else is discarded. If you'd change one of the two to
another non-virtual method then Assign of the one specialization and the
other method of the other specialization would be kept.
If you use virtual methods inside generics then things are less likely to
be removed.
Regards,
Sven
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190716/88b46bed/attachment-0001.html>
More information about the fpc-devel
mailing list