Am So., 2. Dez. 2018, 23:29 hat Bart geschrieben:
> Hi,
>
> { TFoo }
>
> generic TFoo = class
> procedure Bar;
> end;
>
> { TFoo }
>
> procedure TFoo.Bar;
> procedure localproc;
> begin end;
> begin
> end;
>
> This will not compile (fpc 3.0.4):
> gentest.lpr(35,4) Error: Generic met
Am Mo., 3. Dez. 2018, 03:45 hat Ryan Joseph
geschrieben:
>
>
> > On Dec 2, 2018, at 10:53 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Specialization is expensive. If specialization can be avoided, it should
> be. Not to mention that the non-generic one could
> On Dec 2, 2018, at 10:53 PM, Sven Barth via fpc-pascal
> wrote:
>
> Specialization is expensive. If specialization can be avoided, it should be.
> Not to mention that the non-generic one could have more optimized code.
> Though to be sure I'll test with Delphi, we'll have to be compatible
Hi,
{ TFoo }
generic TFoo = class
procedure Bar;
end;
{ TFoo }
procedure TFoo.Bar;
procedure localproc;
begin end;
begin
end;
This will not compile (fpc 3.0.4):
gentest.lpr(35,4) Error: Generic methods cannot have nested procedures
While the message is clear, the reason for this
Am So., 2. Dez. 2018, 15:28 hat Ryan Joseph
geschrieben:
>
>
> > On Dec 2, 2018, at 8:11 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Also the idea should be that a non-generic routine takes precedence.
> >
>
> I did this wrong then because the generic takes p
I just tested and my code has the same behavior as the explicit specialization
(as expected), i.e. last wins, regardless of generic status.
procedure DoThis(msg:integer);
begin
writeln('DoThis:',msg);
end;
generic procedure DoThis(msg:T);
begin
writeln('DoThis$1#1:',msg);
end;
b
> On Dec 2, 2018, at 8:11 PM, Sven Barth via fpc-pascal
> wrote:
>
> Also the idea should be that a non-generic routine takes precedence.
>
I did this wrong then because the generic takes precedence now. Why shouldn’t
the generic take precedence though? It comes after so you think it would
Pada tanggal Min, 2 Des 2018 pukul 15.59 Sven Barth <
pascaldra...@googlemail.com> menulis:
>
> Um... The CRT unit is a raw Pascal solution?! Anyway, you can use that
> unit to see how the CRT unit did it.
>
Nope, I don't think so. CRT unit is Turbo Pascal's legacy unit. There are
some serious ca
Hi Sven
> Where is it messy? O.o
See https://bugs.freepascal.org/view.php?id=28824
> Also the idea should be that a non-generic routine takes precedence.
Seems reasonable.
--
Regards,
Denis Golovan
___
fpc-pascal maillist - fpc-pascal@lists.freep
Am So., 2. Dez. 2018, 10:55 hat denisgolovan
geschrieben:
> Hi Ryan
>
> That's definitely a nice feature.
> Could you clarify and/or discuss with compiler devs the rules for function
> overloads?
> Currently FPC seems a bit messy even without inferencing like that.
>
Where is it messy? O.o
Also
Hi Ryan
That's definitely a nice feature.
Could you clarify and/or discuss with compiler devs the rules for function
overloads?
Currently FPC seems a bit messy even without inferencing like that.
BR,
Denis
___
fpc-pascal maillist - fpc-pascal@lists.
Since I had was already working on generics I wanted to see if I could
implement the inferred specializations like is available in Delphi. The current
syntax is too verbose to be usable so this is a necessary improvement in my
opinion.
Here’s a first draft which seems to be working. There’s pro
Am So., 2. Dez. 2018, 08:29 hat Mr Bee via fpc-pascal <
fpc-pascal@lists.freepascal.org> geschrieben:
> – I want to avoid CRT unit as much as possible. I prefer raw pascal
> solution.
>
Um... The CRT unit is a raw Pascal solution?! Anyway, you can use that unit
to see how the CRT unit did it.
–
13 matches
Mail list logo
