> On Apr 23, 2022, at 5:18 AM, Martin Frb via fpc-pascal
> wrote:
>
> Done
> https://gitlab.com/freepascal.org/fpc/source/-/issues/39684
> https://gitlab.com/freepascal.org/fpc/source/-/issues/39685
It looks like I need to do some cleanup phase. I can’t remember how it works
right now but I
Possible one more / Though more of an optimization.
If the code has multiple
Add(Int64(0), Int64(0));
then they will all use the same procedure (just break in the debugger
and check the CRC).
But if one specialization is explicit and the other implicit then 2
identical (as far as I can t
On 22/04/2022 23:12, Sven Barth via fpc-pascal wrote:
Am 22.04.2022 um 20:51 schrieb Martin Frb via fpc-pascal:
So why does it generate "Add$1" if it does not use it? (Or rather why
does it warn, if this is some internal details?)
Add$1 is the symbol of the generic itself, *not* the special
Am 22.04.2022 um 22:22 schrieb Mattias Gaertner via fpc-pascal:
On Fri, 22 Apr 2022 20:51:56 +0200
Martin Frb via fpc-pascal wrote:
[...]
Well, I tested: It uses the type of the first Param. So it calls a
function for both param of type Byte. The cardinal argument is
converted. (potentially tr
Am 22.04.2022 um 20:51 schrieb Martin Frb via fpc-pascal:
I created a little test program (see bottom of mail).
And it gives a strange warning:
Compile Project, Target:
C:\Users\martin\AppData\Local\Temp\project1.exe: Success, Warnings: 1,
Hints: 3
project1.lpr(67,52) Warning: Range check err
Am Freitag, 22. April 2022, 19:53:34 CEST schrieben Sie:
> Am 22.04.2022 um 15:48 schrieb Rainer Stratmann via fpc-pascal:
> > Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-
pascal:
> We don't deal in percentages, however it reduces the amount of typing
> required to write
On Fri, 22 Apr 2022 20:51:56 +0200
Martin Frb via fpc-pascal wrote:
>[...]
> Well, I tested: It uses the type of the first Param. So it calls a
> function for both param of type Byte. The cardinal argument is
> converted. (potentially truncated).
I agree that Delphi should have used a better a
On Fri, 22 Apr 2022 20:51:56 +0200
Martin Frb via fpc-pascal wrote:
>[...]
> I did explore what happens if I throw different types at it, and see
> how the current implementation deals with this (what I call) lack of
> type safety.
> And also asked the question, how should it act? (Because the c
On 20/04/2022 19:15, Sven Barth via fpc-pascal wrote:
This feature allows you to use generic routines (functions,
procedures, methods) without explicitely specializing them (“<…>” in
Delphi modes and “specialize …<…>” in non-Delphi modes) as long as the
compiler can determine the correct parame
Am 22.04.2022 um 15:48 schrieb Rainer Stratmann via fpc-pascal:
Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-pascal:
This feature is enabled with the modeswitch
ImplicitFunctionSpecialization and is for now not enabled by default as
this has the potential to break existi
On 22/04/2022 17:13, Rainer Stratmann via fpc-pascal wrote:
Am Freitag, 22. April 2022, 17:27:33 CEST schrieb Hairy Pixels via fpc-pascal:
On Apr 22, 2022, at 8:48 PM, Rainer Stratmann via fpc-pascal
From assembly to high-level language there is a huge step.
From high-level language to implici
Am Freitag, 22. April 2022, 17:27:33 CEST schrieb Hairy Pixels via fpc-pascal:
> > On Apr 22, 2022, at 8:48 PM, Rainer Stratmann via fpc-pascal
> It’s like everything else in programming languages.
>
> 1) you can specialize the function manually so implicit specialization is
> not needed.
> 2) y
> On Apr 22, 2022, at 8:48 PM, Rainer Stratmann via fpc-pascal
> wrote:
>
> How many percent of the users need this feature?
> Is it a feature that is a must?
> Can everyone get also a solution without the feature?
> Does it justify the risk of the whole language (has the potential to break
>
Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-pascal:
> This feature is enabled with the modeswitch
> ImplicitFunctionSpecialization and is for now not enabled by default as
> this has the potential to break existing code.
How many percent of the users need this feature?
Is
> If you want to pass a pointer to ^T in a generic function is there anyway
> safe to do this currently? Pascal doesn’t allow ^ types in function arguments
> (why?) and generics don’t seems to support pointers either (why?).
>
> generic TValues = array[0..0] of T;
> generic PValues = ^speciali
15 matches
Mail list logo
