Re: [fpc-pascal] Generics in Objective Pascal?

[Ryan Joseph via fpc-pascal]

> On Nov 2, 2020, at 1:30 PM, Zoë Peterson via fpc-pascal 
>  wrote:
> 
> I have an NSView subclass with a bunch of fields and methods, and I wanted to 
> be able to optionally swap that out with a parallel version derived from 
> NSVisualEffectView without duplicating all of the code.  I was hoping that 
> adding generics to objcclass would be relatively trivial and just hadn't been 
> asked for, but I know how assuming that usually goes.

Hmmm It sounds like once again Pascal needs "traits" or some other way to do 
composition? I'm extremely keep to develop such feature if the team wouuld 
decide on some syntax and principles (I had a thread about this some months ago 
if you search).

In mean time I guess you could try include files and ifdefs in some clever way. 
Not pretty but maybe it's better then keeping lots of duplicated code or doing 
big refactors.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics in Objective Pascal?

[Zoë Peterson via fpc-pascal]

On 11/2/20 1:01 PM, Ryan Joseph via fpc-pascal wrote:

What are you trying to do exactly? There are categories in ObjC but those don't 
allow fields (they're like helpers in Object Pascal). If you need to share data 
between a bunch of different NSView subclasses then all you can do is make a 
common subclass or make the shared data a class of its own and pass that into 
all your subclasses. Nothing ObjC related about that however but I'm not sure 
what you're trying to do.


I have an NSView subclass with a bunch of fields and methods, and I 
wanted to be able to optionally swap that out with a parallel version 
derived from NSVisualEffectView without duplicating all of the code.  I 
was hoping that adding generics to objcclass would be relatively trivial 
and just hadn't been asked for, but I know how assuming that usually goes.


More specifically, under LCL/Cocoa, TCustomControl's Handle uses a 
TCocoaManualScrollView(NSView) (in 
lcl/interfaces/cocoa/cocoascrollers.pas) that has a bunch of code to 
interact with the LCL objects.  When running recent versions of macOS in 
dark mode, custom controls like TTreeView actually use a 
behind-the-window blur rather than a plain clWindow FillRect.  Since a 
lot of the TCocoaManualScrollView interaction is just general NSView 
messages or LCL protocol/category extensions, I figured I could keep the 
changes fairly small if I was able to just swap in a 
TCocoaManualScrollView, which would avoid 
introducing another view in the hierarchy, keep the code cleaner, and 
be easier to disable if MACOS_MINIMUM_DEPLOYMENT_TARGET < 10.10.


I should be able to make it work with composition and re-parenting 
things when necessary, but there will be a lot more management code, so 
I thought I'd ask.


--
Zoë Peterson
Scooter Software

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics in Objective Pascal?

[Ryan Joseph via fpc-pascal]

> On Nov 1, 2020, at 8:45 AM, Zoë Peterson via fpc-pascal 
>  wrote:
> 
> I'd like to have a generic objcclass that would add some extra functionality 
> for multiple base types.  I don't have a lot of experience with generics, but 
> this compiles:
> 

Waiting for Jonas to reply but I'm pretty certain this is a feature never 
implemented. I've been working with generics in the compiler recently and I 
don't see any reason why they would be hard to implement but maybe Jonas knows 
the answer.

What are you trying to do exactly? There are categories in ObjC but those don't 
allow fields (they're like helpers in Object Pascal). If you need to share data 
between a bunch of different NSView subclasses then all you can do is make a 
common subclass or make the shared data a class of its own and pass that into 
all your subclasses. Nothing ObjC related about that however but I'm not sure 
what you're trying to do.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics in Objective Pascal?

[Zoë Peterson via fpc-pascal]

I'd like to have a generic objcclass that would add some extra 
functionality for multiple base types.  I don't have a lot of experience 
with generics, but this compiles:

--
generic TMyControl = class(T)
  private
    FField: string;
procedure Foo;
  end;
  TMyEdit = specialize TMyControl;
--

and this fails with the error 'Class or interface type expected, but got 
"NSView"':

--
  generic NSMyView = objcclass(T)
  private
    FField: string;
    procedure Foo; message 'Foo:';
  end;
--

The documentation doesn't mention it, so I'm assuming it's just not 
implemented.  Is that something that could be supported?  Would it be 
difficult to do so?  Are there any existing Objective Pascal specific 
tricks I could use to avoid duplicating all of the fields/code?

Thanks!
Zoë Peterson
Scooter Software
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics in Objective-C mode bug?

[Ryan Joseph via fpc-pascal]

> On Nov 11, 2019, at 1:25 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> Generics are not considered supported with Objective Pascal types. 
> 

There's really not any reason they shouldn't though. If you specialized with 
"string" for example that wouldn't be anything out of the ordinary so why does 
it matter if it's generic or not? Maybe Jonas has a reason I don't know about.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics in Objective-C mode bug?

[Sven Barth via fpc-pascal]

Ryan Joseph via fpc-pascal  schrieb am
Mo., 11. Nov. 2019, 19:21:

> Is this a bug I should report? Knowing what I do about generics now I
> think the type check needs to be suspended until the type is actually
> specialized.
>

Generics are not considered supported with Objective Pascal types.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics in Objective-C mode bug?

[Ryan Joseph via fpc-pascal]

Is this a bug I should report? Knowing what I do about generics now I think the 
type check needs to be suspended until the type is actually specialized.


{$mode objfpc}
{$modeswitch objectivec2}

program test;

type
  generic TCocoaObject = objcclass (NSObject)
// ERROR: The type "TCocoaObject$1.T" is not supported for interaction with 
the Objective-C and the blocks runtime.
m_obj: T;
function obj: T; message 'obj';
  end;

function TCocoaObject.obj: T;
begin
  result := m_obj;
end;

begin
end.


Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics: Error: Can't determine which overloaded function to call

[LacaK]

Work-around which produces good assembler without writting/reading 
intermediate variables:


class function T2DPoint.Sqr(value: T): T; static; inline;
begin
  Result := value*value;
end;

function T2DPoint.Distance(P: T2DPoint): Single; inline;
begin
  Result := Sqrt(Sqr(x-P.x) + Sqr(y-P.y));
end;




Is there other solution as:

function T2DPoint.Distance(P: T2DPoint): Single;
var dx,dy: T;
begin
  dx := x-P.x;
  dy := y-P.y;
  Result := Sqrt(dx*dx + dy*dy);
end;

(for integer operations Sqr() is implemented as "value*value", so 
there is no difference (compared to above mentioned implementation) 
but for floating point operations there is called internal function 
"fpc_in_sqr_real" which is IMO implemented in smarter way that 
"value*value" (I can not find where/how is implemented)?)


TIA

-Laco.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics: Error: Can't determine which overloaded function to call

[LacaK]

Hi *,

I have generics record, where one method computes distance between 2 points:

function T2DPoint.Distance(P: T2DPoint): Single;
begin
  Result := Sqrt(Sqr(x-P.x) + Sqr(y-P.y));
end;

But this does not compile as there are many versions of Sqr() in the 
scope Sqr(longint), Sqr(QWord), Sqr(Extended), Sqr(int64)


Point coordinates (x,y) can be either integer or single (in my case) 
when specializing, so decision which version of Sqr() to call should be 
postponed to specializing phase, does not?


Is there other solution as:

function T2DPoint.Distance(P: T2DPoint): Single;
var dx,dy: T;
begin
  dx := x-P.x;
  dy := y-P.y;
  Result := Sqrt(dx*dx + dy*dy);
end;

(for integer operations Sqr() is implemented as "value*value", so there 
is no difference (compared to above mentioned implementation) but for 
floating point operations there is called internal function 
"fpc_in_sqr_real" which is IMO implemented in smarter way that 
"value*value" (I can not find where/how is implemented)?)


TIA

-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics question

[Martok]

Am 03.12.2018 um 10:53 schrieb Martok:
> I'll have to check the real-world code again, might be able to close this bug 
> as
> "fixed in the mean time".
Checked, works also in real code.

I have added a note saying so on the bug.

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics question

[Sven Barth via fpc-pascal]

Am Mo., 3. Dez. 2018, 10:53 hat Martok 
geschrieben:

> Am 03.12.2018 um 08:00 schrieb Sven Barth via fpc-pascal:
> > Because Delphi does not allow that either. We relaxed that however in
> 3.1.1 and
> > it should be part of 3.2.0. You can test the corresponding branch of you
> want.
>
> Is this related to  ?
> The example I provided then doesn't crash anymore, but it sounds like that
> is
> the sort of code that would not be accepted at all in Delphi?
>
> I'll have to check the real-world code again, might be able to close this
> bug as
> "fixed in the mean time".
>

Yes, I fixed something related to nested procs some weeks ago and yes,
Delphi does not support that (and some other things we support, but they
don't :D ).

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics question

[Martok]

Am 03.12.2018 um 08:00 schrieb Sven Barth via fpc-pascal:
> Because Delphi does not allow that either. We relaxed that however in 3.1.1 
> and
> it should be part of 3.2.0. You can test the corresponding branch of you 
> want. 

Is this related to  ?
The example I provided then doesn't crash anymore, but it sounds like that is
the sort of code that would not be accepted at all in Delphi?

I'll have to check the real-world code again, might be able to close this bug as
"fixed in the mean time".

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics question

[Sven Barth via fpc-pascal]

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 methods cannot have nested procedures
>
> While the message is clear, the reason for this is not (to me at last).
>
> Does anybody know why?
>

Because Delphi does not allow that either. We relaxed that however in 3.1.1
and it should be part of 3.2.0. You can test the corresponding branch of
you want.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics question

[Bart]

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 is not (to me at last).

Does anybody know why?

Bart
-- 
Bart
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics - extending TFPGObjectList

[Sven Barth via fpc-pascal]

Vojtěch Čihák  schrieb am Do., 26. Juli 2018, 13:40:

> Thanks for reply.
>
>
>
> Ad 2) I opened issue: https://bugs.freepascal.org/view.php?id=34037
>
>
>
> Ad 1) Are there any plans for improvement of generic inheritance? Related
> to my example, instead of
>
>
>
> generic TFPGObjectListEx = class (specialize
> TFPGObjectList)
>
>
>
> I would prefer simplier and more straightforward
>
>
>
> generic TFPGObjectListEx = class (TFPGObjectList)
>
>
>
> which will give programmers possibility to extend classes from FGL without
> any further constraints.
>
>
>
> What if I fill feature request? :-)
>
I have no intention of changing this.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics - extending TFPGObjectList

[Vojtěch Čihák]

Thanks for reply.
 
Ad 2) I opened issue: https://bugs.freepascal.org/view.php?id=34037
 
Ad 1) Are there any plans for improvement of generic inheritance? Related to my 
example, instead of
 
    generic TFPGObjectListEx = class (specialize TFPGObjectList)
 
I would prefer simplier and more straightforward
 
    generic TFPGObjectListEx = class (TFPGObjectList)
 
which will give programmers possibility to extend classes from FGL without any 
further constraints.
 
What if I fill feature request? :-)
 
Vojtěch
 
__

Od: Sven Barth via fpc-pascal 
Komu: fpc-pascal@lists.freepascal.org
Datum: 26.07.2018 07:04
Předmět: Re: [fpc-pascal] Generics - extending TFPGObjectList


Am 26.07.2018 um 02:31 schrieb Vojtěch Čihák:Hello,
 
I needed to extend TFPGObjectList and I found two wierd things (FPC 3.1.1 
r39507):
 
program project1;
{$mode objfpc}{$H+}
 
uses
  Classes, FGL;
 
type
  TBaseClass = class (TObject)
  end;
 
  TIDClass = class (TBaseClass)
    ID: Integer;
  end;
 
  TNameIDClass = class (TIDClass)
    Name: string;
  end;
 
  generic TFPGObjectListEx = class (specialize 
TFPGObjectList) //1 A
    function GetItemByID(AID: Integer): T;
  end;
 
  TNameIDList = class (specialize TFPGObjectListEx)
 
  end;
 
{$R *.res}
 
function TFPGObjectListEx.GetItemByID(AID: Integer): T;
begin
  {...}
  Result:=nil; //2
end;
 
var NameIDList: TNameIDList;
    NameID: TNameIDClass;
begin
  NameID:=NameIDList.Items[0]; //1 B
end.
 
The demo does not compile because of two errors:
1) project1.lpr(38,21) Error: Incompatible types: got "TBaseClass" expected 
"TNameIDClass" at comment //1 B
It is caused by declaration at //1 A. Class TFPGObjectListEx can be really 
generic only if it is declared like this:
   generic TFPGObjectListEx = class (specialize TFPGObjectList) //1 
A, otherwise you must retype TNameIDClass(Items[0]) and it is against the philosophy of generics. 
Isn't it meaningless? Why there must be specialize to  when in fact it is no 
specialization at all.

You are not overriding the Items property, thus it will still be the Items property 
of TFPGObjectList and thus the compiler will rightfully complain at 
location 1 B. Using generics does not absolve you from usual inheritance problems.

 
2) project1.lpr(32,11) Error: Incompatible types: got "Pointer" expected 
"$gendef4" at comment //2
The line must be changed to
  Result:=T(nil);
which seems bizarre to me, I've never seen retyping "nil". Even more, both TFPGObjectList and 
TFPGObjectListEx are constrained to TObject and to TIDClass so there is safety, TFPGObjectListEx can be only 
specialized with types that have "nil" ( can never be , for example).
Well, no one said that the generics are completely bug free... Especially in 
special situations that involve either Nil or type constraints (or in this case 
both). Please provide a simple example and open a bug report.

Regards,
Sven


--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal 
<http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics - extending TFPGObjectList

[Sven Barth via fpc-pascal]

Am 26.07.2018 um 02:31 schrieb Vojtěch Čihák:


Hello,

I needed to extend TFPGObjectList and I found two wierd things (FPC 
3.1.1 r39507):


program project1;

{$mode objfpc}{$H+}

uses

  Classes, FGL;

type

  TBaseClass = class (TObject)

  end;

  TIDClass = class (TBaseClass)

    ID: Integer;

  end;

  TNameIDClass = class (TIDClass)

    Name: string;

  end;

  generic TFPGObjectListEx = class (specialize 
TFPGObjectList) //1 A


    function GetItemByID(AID: Integer): T;

  end;

  TNameIDList = class (specialize TFPGObjectListEx)

  end;

{$R *.res}

function TFPGObjectListEx.GetItemByID(AID: Integer): T;

begin

  {...}

  Result:=nil; //2

end;

var NameIDList: TNameIDList;

    NameID: TNameIDClass;

begin

NameID:=NameIDList.Items[0]; //1 B

end.

The demo does not compile because of two errors:

1) project1.lpr(38,21) Error: Incompatible types: got "TBaseClass" 
expected "TNameIDClass" at comment //1 B


It is caused by declaration at //1 A. Class TFPGObjectListEx can be 
really generic only if it is declared like this:


   generic TFPGObjectListEx = class (specialize 
TFPGObjectList) //1 A, otherwise you must retype 
TNameIDClass(Items[0]) and it is against the philosophy of generics. 
Isn't it meaningless? Why there must be specialize to  when in fact 
it is no specialization at all.




You are not overriding the Items property, thus it will still be the 
Items property of TFPGObjectList and thus the compiler will 
rightfully complain at location 1 B. Using generics does not absolve you 
from usual inheritance problems.


2) project1.lpr(32,11) Error: Incompatible types: got "Pointer" 
expected "$gendef4" at comment //2


The line must be changed to

  Result:=T(nil);

which seems bizarre to me, I've never seen retyping "nil". Even more, 
both TFPGObjectList and TFPGObjectListEx are constrained to TObject 
and to TIDClass so there is safety, TFPGObjectListEx can be only 
specialized with types that have "nil" ( can never be , 
for example).


Well, no one said that the generics are completely bug free... 
Especially in special situations that involve either Nil or type 
constraints (or in this case both). Please provide a simple example and 
open a bug report.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics - extending TFPGObjectList

[Vojtěch Čihák]

Hello,
 
I needed to extend TFPGObjectList and I found two wierd things (FPC 3.1.1 
r39507):
 
program project1;
{$mode objfpc}{$H+}
 
uses
  Classes, FGL;
 
type
  TBaseClass = class (TObject)
  end;
 
  TIDClass = class (TBaseClass)
    ID: Integer;
  end;
 
  TNameIDClass = class (TIDClass)
    Name: string;
  end;
 
  generic TFPGObjectListEx = class (specialize 
TFPGObjectList) //1 A
    function GetItemByID(AID: Integer): T;
  end;
 
  TNameIDList = class (specialize TFPGObjectListEx)
 
  end;
 
{$R *.res}
 
function TFPGObjectListEx.GetItemByID(AID: Integer): T;
begin
  {...}
  Result:=nil; //2
end;
 
var NameIDList: TNameIDList;
    NameID: TNameIDClass;
begin
  NameID:=NameIDList.Items[0]; //1 B
end.
 
The demo does not compile because of two errors:
1) project1.lpr(38,21) Error: Incompatible types: got "TBaseClass" expected 
"TNameIDClass" at comment //1 B
It is caused by declaration at //1 A. Class TFPGObjectListEx can be really 
generic only if it is declared like this:
   generic TFPGObjectListEx = class (specialize TFPGObjectList) //1 
A, otherwise you must retype TNameIDClass(Items[0]) and it is against the philosophy of generics. 
Isn't it meaningless? Why there must be specialize to  when in fact it is no 
specialization at all.
 
2) project1.lpr(32,11) Error: Incompatible types: got "Pointer" expected 
"$gendef4" at comment //2
The line must be changed to
  Result:=T(nil);
which seems bizarre to me, I've never seen retyping "nil". Even more, both TFPGObjectList and 
TFPGObjectListEx are constrained to TObject and to TIDClass so there is safety, TFPGObjectListEx can be only 
specialized with types that have "nil" ( can never be , for example).
 
Thanks,
 
Vojtěch.
 
PS: The demo crashes.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 11.01.2018 08:06 schrieb "Michael Schnell" :

On 09.01.2018 08:04, Sven Barth via fpc-pascal wrote:

But you need to program in a way that allows the usage of multiple,
different types. That can more often than not lead to worse performance.

Seemingly it is done that way.

I rather often did a kind of "Generics" in ANSI C by using Macros. It's
catastrophic for code writing and for debugging but does not impose any
performance issues.

I suppose there is a reason why in Pascal Generics are not translated in
multiple dedicatedly typed code snippets at compile time.


Huh? A generic is reparsed for every type tuple it is specialized with
(except of course it already finds an existing previous specialization for
these types), but you need to write the generic's code in a way that
satisfies the parser for all these types (though FPC is more lenient here
than Delphi).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Michael Schnell]

On 09.01.2018 08:04, Sven Barth via fpc-pascal wrote:
But you need to program in a way that allows the usage of multiple, 
different types. That can more often than not lead to worse performance.

Seemingly it is done that way.

I rather often did a kind of "Generics" in ANSI C by using Macros. It's 
catastrophic for code writing and for debugging but does not impose any 
performance issues.


I suppose there is a reason why in Pascal Generics are not translated in 
multiple dedicatedly typed code snippets at compile time.


-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 10.01.2018 05:10 schrieb "Ryan Joseph" :



> On Jan 10, 2018, at 6:37 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
>
> When using the Generics.Collections unit of Delphi I can define a list
class that can hold Integer data types, by doing the following:
>
>  var
>IntList: TList;
>  begin
>IntList := TList.Create;
>IntList.Add(12345);

I presume then TList<> and TList class are not implemented the same then
because I still don’t know how the generic itself affects runtime
performance.

Btw this looks like C# code because C# explicitly does not specialize at
compile time but rather runtime so every instance will be using
TList. Does Delphi do this also? I think FPC requires you MUST
specialize at compile time so simply using TList won’t compile.


That are two orthogonal points. FPC and Delphi both allow inline
specializations which is what you see above (in the non-Delphi modes of
course with the "specialize" keyword). That doesn't change that such
specializations are done at compile time. For the compiler it is as if the
type "TList" exists as a full type wherever it is used.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 10.01.2018 07:39 schrieb "Marco van de Voort" :

In our previous episode, Sven Barth via fpc-pascal said:
> Precisely these virtual methods are one point. They might not add much by
> themselves, but if they're called for each Add or Remove operation they
can
> add quite a bit.
> Why do you think that the TFP(Object)List classes don't have notification
> support unlike T(Object)List? Even if it only checks whether a
notification
> handler is assigned it's enough for a noticeable difference in
performance.

But Graeme compared Delphi TList to Delphi TList<> so both have notifiers?


That was more about what a difference the existence of notifiers can have
to highlight what performance difference generic capable code can have
compared to non-generic code.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-pascal said:
> Precisely these virtual methods are one point. They might not add much by
> themselves, but if they're called for each Add or Remove operation they can
> add quite a bit.
> Why do you think that the TFP(Object)List classes don't have notification
> support unlike T(Object)List? Even if it only checks whether a notification
> handler is assigned it's enough for a noticeable difference in performance.

But Graeme compared Delphi TList to Delphi TList<> so both have notifiers?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Ryan Joseph]

> On Jan 10, 2018, at 6:37 AM, Graeme Geldenhuys 
>  wrote:
> 
> When using the Generics.Collections unit of Delphi I can define a list class 
> that can hold Integer data types, by doing the following:
> 
>  var
>IntList: TList;
>  begin
>IntList := TList.Create;
>IntList.Add(12345);

I presume then TList<> and TList class are not implemented the same then 
because I still don’t know how the generic itself affects runtime performance.

Btw this looks like C# code because C# explicitly does not specialize at 
compile time but rather runtime so every instance will be using TList. 
Does Delphi do this also? I think FPC requires you MUST specialize at compile 
time so simply using TList won’t compile.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Graeme Geldenhuys]

On 2018-01-09 01:29, Ryan Joseph wrote:

What does this have to do with generics exactly?


Everything I guess. ;-) That was the point of my reply.

When using the Generics.Collections unit of Delphi I can define a list 
class that can hold Integer data types, by doing the following:


  var
IntList: TList;
  begin
IntList := TList.Create;
IntList.Add(12345);

How Generics does that (how it is implemented underneath), I don't know 
- I never bothered to look. All I'm saying is that in our company the 
developers love Generics, but then can't understand why performance 
degrades is some areas of our project. Further testing revealed that the 
usage of Generics was partly to blame.


I then investigated this, and compared some of those lists, and 
implementing the equivalent manually (using TList, TObjectList and 
such). For example, the above code example can be accomplish with a 
TList only.


  var
IntList: TList;
  begin
IntList := TList.Create;
IntList.Add(Pointer(12345));

Yes, the second code sample might not look so nice (the casting), but it 
was just the simplest and quickest example I could knock up to store 
integers in a list. Either way, the non-Generics code example was 
considerably faster in adding and freeing itself.


This was just one example. TObjectList (or a customised descendant... 
eg: TAddressList) was another case where it was way faster than 
Generics.Collections.pas unit provided.


Like I said, this was all tested under Delphi XE3. I didn't have time 
today to test under FPC, but will try and do so tomorrow.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Maciej Izak]

2018-01-08 21:30 GMT+01:00 Graeme Geldenhuys 
:

> Speaking of Generics and Benchmarks. Has anybody done some benchmarks on
> FPC's Generics vs "old-school" TList and TObjectList. Recently I did a very
> simple test with Delphi XE3 using TList and a stock TList. Adding
> 50,000 and 200,000 integer values to each list, and timing the creation of
> the list and population of the list. Then I also timed the destruction of
> the list. I was horified to find out how much slower Delphi's Generics were
> compared to TList and TObjectList. Destruction was 250x slower in many
> cases. Creation and population of the list was 5x-10x slower.
>
> Lets hope FPC fares better. If nobody has done such tests, I can do it
> tomorrow at work with the same Delphi test code I created.
>

It depends on use case and on library design. For example in the FPC case,
generic TList has better performance for larger lists (the capacity uses
golden ratio) than regular TList (for Integers). The performance difference
in daily usage is rather minor (if any).

We have available detailed tests for generic and non generics hash maps
thanks to Benito van der Zander (FPC has so many different maps! :) ):

http://www.benibela.de/fpc-map-benchmark_en.html

The results for rtl-generics should be better soon. I am working on new
version of rtl-generics library, so all should works faster (better hashing
function + optimizations for managed types - especially improved for
incoming smart pointers/objects).

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 09.01.2018 08:13 schrieb "Ryan Joseph" :



> On Jan 9, 2018, at 2:04 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>
> But you need to program in a way that allows the usage of multiple,
different types. That can more often than not lead to worse performance.
>

Examples? I had to add some if statements in a couple areas I didn’t want
to and a virtual method but beyond that I don’t see what would affect
performance.


Precisely these virtual methods are one point. They might not add much by
themselves, but if they're called for each Add or Remove operation they can
add quite a bit.
Why do you think that the TFP(Object)List classes don't have notification
support unlike T(Object)List? Even if it only checks whether a notification
handler is assigned it's enough for a noticeable difference in performance.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Ryan Joseph]

> On Jan 9, 2018, at 2:04 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> But you need to program in a way that allows the usage of multiple, different 
> types. That can more often than not lead to worse performance. 
> 

Examples? I had to add some if statements in a couple areas I didn’t want to 
and a virtual method but beyond that I don’t see what would affect performance.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 09.01.2018 02:59 schrieb "Ryan Joseph" :



> On Jan 9, 2018, at 3:30 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
>
> Recently I did a very simple test with Delphi XE3 using TList
and a stock TList. Adding 50,000 and 200,000 integer values to each list,
and timing the creation of the list and population of the list. Then I also
timed the destruction of the list. I was horified to find out how much
slower Delphi's Generics were compared to TList and TObjectList.
Destruction was 250x slower in many cases. Creation and population of the
list was 5x-10x slower.

What does this have to do with generics exactly? If I understand correctly
generics are “meta-programming” where they essentially just re-insert a
generated class based on the template (c++’s naming scheme makes more sense
imo) but they don’t actually add any runtime code.


But you need to program in a way that allows the usage of multiple,
different types. That can more often than not lead to worse performance.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Ryan Joseph]

> On Jan 9, 2018, at 3:30 AM, Graeme Geldenhuys  
> wrote:
> 
> Recently I did a very simple test with Delphi XE3 using TList and a 
> stock TList. Adding 50,000 and 200,000 integer values to each list, and 
> timing the creation of the list and population of the list. Then I also timed 
> the destruction of the list. I was horified to find out how much slower 
> Delphi's Generics were compared to TList and TObjectList. Destruction was 
> 250x slower in many cases. Creation and population of the list was 5x-10x 
> slower.

What does this have to do with generics exactly? If I understand correctly 
generics are “meta-programming” where they essentially just re-insert a 
generated class based on the template (c++’s naming scheme makes more sense 
imo) but they don’t actually add any runtime code.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Giuliano Colla]

Il 08/01/2018 21:30, Graeme Geldenhuys ha scritto:

I was horified to find out how much slower Delphi's Generics were 
compared to TList and TObjectList


I don't expect FPC behave much better. Whenever you move something from 
compile time to execution time you may gain in flexibility, but you 
surely lose in performance. Whenever a generic can be replaced by an if 
.. then .. else .., using a generic is just an useless performance killer.
The same holds true for using a TObject, when a record would be enough 
or for using an Interface instead of just linking the appropriate 
library when this would be possible (see Lazarus vs fpGui!).


Giuliano

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Graeme Geldenhuys]

On 2018-01-08 10:58, Sven Barth via fpc-pascal wrote:

FPC essentially reparses a generic during specialization so I'd say that
they definitely affect compile times. However we're still only doing a
single pass of parsing. This while the compilation might be slower it might
not be as bad as with a C++ compiler.

As far as I know no one has done a benchmark for that however.



Speaking of Generics and Benchmarks. Has anybody done some benchmarks on 
FPC's Generics vs "old-school" TList and TObjectList. Recently I did a 
very simple test with Delphi XE3 using TList and a stock TList. 
Adding 50,000 and 200,000 integer values to each list, and timing the 
creation of the list and population of the list. Then I also timed the 
destruction of the list. I was horified to find out how much slower 
Delphi's Generics were compared to TList and TObjectList. Destruction 
was 250x slower in many cases. Creation and population of the list was 
5x-10x slower.


Lets hope FPC fares better. If nobody has done such tests, I can do it 
tomorrow at work with the same Delphi test code I created.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 08.01.2018 12:52 schrieb "Ryan Joseph" :



> On Jan 8, 2018, at 5:58 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>
> FPC essentially reparses a generic during specialization so I'd say that
they definitely affect compile times.

Does c++  not “specialize” in one location like FPC? looking at c++ code I
often see things like Vector used in multiple locations instead of
declaring a single type (I have no idea why they would do that but it’s
very common). Maybe that’s why compile times are so slow?


C++ specializes once per compilation unit (and per unique type parameters).
FPC does this as well, but in addition it will try to reuse a compatible
specialization that's located in the interface section of a used unit.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Ryan Joseph]

> On Jan 8, 2018, at 5:58 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> FPC essentially reparses a generic during specialization so I'd say that they 
> definitely affect compile times.

Does c++  not “specialize” in one location like FPC? looking at c++ code I 
often see things like Vector used in multiple locations instead of declaring 
a single type (I have no idea why they would do that but it’s very common). 
Maybe that’s why compile times are so slow?

In one instance I did something similar but hopefully it “unfolds” only once 
when the unit compiles. Is that true?

type
generic TStaticArray = class (TObject)
end;

type
generic TDynamicArray = class (specialize TStaticArray)
end;

type
generic TGenericArray = class (specialize TDynamicArray)
end;

type
TIntegerArray = specialize TGenericArray;
TLongIntArray = specialize TGenericArray;
TStringArray = specialize TGenericArray;
TSingleArray = specialize TGenericArray;
TDoubleArray = specialize TGenericArray;
TFloatArray = specialize TGenericArray;
TPointerArray = specialize TGenericArray;

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Mattias Gaertner]

On Mon, 8 Jan 2018 14:19:42 +0700
Ryan Joseph  wrote:

> I was talking with a c++ developer who explained how templates are 
> implemented in c++ and how use some recursive method which causes them to 
> totally murder compile times.
> Having just started to use generics in FPC myself I was curious if FPC 
> suffers from the same problem of slow compile times?

C++ templates are Turing complete. FPC generics are not.

https://en.wikipedia.org/wiki/Template_metaprogramming

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs templates

[Sven Barth via fpc-pascal]

Am 08.01.2018 08:50 schrieb "Ryan Joseph" :

I was talking with a c++ developer who explained how templates are
implemented in c++ and how use some recursive method which causes them to
totally murder compile times. This isn’t the first I’ve heard of the
problem though and I recall some game studios who develop engines in c++
saying they are strictly off limits for the same reasons.

Having just started to use generics in FPC myself I was curious if FPC
suffers from the same problem of slow compile times?


FPC essentially reparses a generic during specialization so I'd say that
they definitely affect compile times. However we're still only doing a
single pass of parsing. This while the compilation might be slower it might
not be as bad as with a C++ compiler.

As far as I know no one has done a benchmark for that however.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics vs templates

[Ryan Joseph]

I was talking with a c++ developer who explained how templates are implemented 
in c++ and how use some recursive method which causes them to totally murder 
compile times. This isn’t the first I’ve heard of the problem though and I 
recall some game studios who develop engines in c++ saying they are strictly 
off limits for the same reasons.

Having just started to use generics in FPC myself I was curious if FPC suffers 
from the same problem of slow compile times?

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Bug

[African Wild Dog]

2017-03-18 19:29 GMT-03:00 African Wild Dog :

> 2017-03-18 18:41 GMT-03:00 Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org>:
>
> Nested specializations are currently not supported though they *might*
>> work with 3.1.1.
>>
>
> I will do test some tests with 3.1.1.  Thanks.
>
> Regards
>

I have tested with 3.1.1. Nested specializations works in 3.1.1.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Bug

[African Wild Dog]

2017-03-18 18:41 GMT-03:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:

Nested specializations are currently not supported though they *might* work
> with 3.1.1.
>

I will do test some tests with 3.1.1.  Thanks.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Bug

[Sven Barth via fpc-pascal]

Am 18.03.2017 22:41 schrieb "Sven Barth" :
>
> Am 18.03.2017 19:55 schrieb "African Wild Dog" :
> >
> > Hello,
> >
> >
> > Please confirm this bug.
> >
> > The unit code bellow won't compile (fpc 3.0.2 - debian jessie amd64):
> >
> > "generics_bug.pas(17,48) Fatal: Syntax error, "," expected but "<"
found"
> >
> > === CODE  ===
> >
> > unit generics_bug;
> >
> > {$mode delphi}
> >
> > interface
> >
> > type
> >
> >   TPair = record
> > Key: TKey;
> > Value: TValue;
> >   end;
> >
> >   TEnumerator = class
> >   end;
> >
> >   TGenericClass = class(TEnumerator>)
> >   end;
> >
> > implementation
> >
> > end.
> >
> > ===
>
> Nested specializations are currently not supported though they *might*
work with 3.1.1.

Note: "they" in the sense of "this specific case".

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Bug

[Sven Barth via fpc-pascal]

Am 18.03.2017 19:55 schrieb "African Wild Dog" :
>
> Hello,
>
>
> Please confirm this bug.
>
> The unit code bellow won't compile (fpc 3.0.2 - debian jessie amd64):
>
> "generics_bug.pas(17,48) Fatal: Syntax error, "," expected but "<" found"
>
> === CODE  ===
>
> unit generics_bug;
>
> {$mode delphi}
>
> interface
>
> type
>
>   TPair = record
> Key: TKey;
> Value: TValue;
>   end;
>
>   TEnumerator = class
>   end;
>
>   TGenericClass = class(TEnumerator>)
>   end;
>
> implementation
>
> end.
>
> ===

Nested specializations are currently not supported though they *might* work
with 3.1.1.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics Bug

[African Wild Dog]

Hello,


Please confirm this bug.

The unit code bellow won't compile (fpc 3.0.2 - debian jessie amd64):

"generics_bug.pas(17,48) Fatal: Syntax error, "," expected but "<" found"

=== CODE  ===

*unit* generics_bug;

{$mode delphi}

*interface*

*type*

  TPair = *record*
Key: TKey;
Value: TValue;
  *end*;

  TEnumerator = *class*
  *end*;

  TGenericClass = *class*(TEnumerator>)
  *end*;

*implementation*

*end*.

===


This code compiles in Delphi XE 2.

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and Scopes

[Sven Barth]

Am 10.11.2016 04:30 schrieb "African Wild Dog" :
>
> 2016-11-07 14:15 GMT-02:00 Sven Barth :
>>
>> Am 07.11.2016 15:58 schrieb "African Wild Dog" :
>> > It is intended to change such compiler behavior in the future? It is
incompatible with Delphi and moreover it force us to break the
encapsulation of the Generic types.
>>
>> I can't answer this without you providing an example that fails.
>
>
> Sorry for the noise. Some of my classes were bad designed. They look like
this sample (Delphi XE 6 compiles):
>
>  CODE BEGIN 
>
> unit sample;
>
> {$MODE delphi}
>
> interface
>
> type
>   TGenericRecord = record
>   strict private
> Interf: IInterface;
> type
>   TMockIntfObject = record // Nested generic declaration
>   end;
>
>   public
> FValue: T;
> procedure SetValue(Value: T);
>   end;
>
> implementation
>
> { TGenericRecord }
>
> procedure TGenericRecord.SetValue(Value: T);
> begin
>   Interf := TMockIntfObject.Create;
> end;
>
> end.
>
>
>  END 
>
>
>  With fpc i got the error "Fatal: Declation of generic class inside
another generic class is not allowed".

Nested generics are currently indeed not supported. They are on my ToDo
list however.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and Scopes

[African Wild Dog]

2016-11-10 1:30 GMT-02:00 African Wild Dog :

> 2016-11-07 14:15 GMT-02:00 Sven Barth :
>
>> Am 07.11.2016 15:58 schrieb "African Wild Dog" :
>> > It is intended to change such compiler behavior in the future? It is
>> incompatible with Delphi and moreover it force us to break the
>> encapsulation of the Generic types.
>>
>> I can't answer this without you providing an example that fails.
>>
>
> Sorry for the noise. Some of my classes were bad designed. They look like
> this sample (Delphi XE 6 compiles):
>
>  CODE BEGIN 
>
> unit sample;
>
> {$MODE delphi}
>
> interface
>
> type
>   TGenericRecord = record
>   strict private
> Interf: IInterface;
> type
>   TMockIntfObject = record // Nested generic declaration
>   end;
>
>   public
> FValue: T;
> procedure SetValue(Value: T);
>   end;
>
> implementation
>
> { TGenericRecord }
>
> procedure TGenericRecord.SetValue(Value: T);
> begin
>   Interf := TMockIntfObject.Create;
> end;
>
> end.
>
>
>  END 
>
>
>  With fpc i got the error "Fatal: Declation of generic class inside
> another generic class is not allowed".
>
> Best regards
>
>
This is the correct sample:

=== CODE BEGIN ===

unit sample;

{$MODE delphi}

interface

type
  TGenericRecord = record
  strict private
type
  TMockRecord = record // Nested generic declaration
  end;

  public
FValue: T;
procedure SetValue(Value: T);
  end;

implementation

{ TGenericRecord }

procedure TGenericRecord.SetValue(Value: T);
begin
end;

end.


=== END ===

Regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and Scopes

[African Wild Dog]

2016-11-07 14:15 GMT-02:00 Sven Barth :

> Am 07.11.2016 15:58 schrieb "African Wild Dog" :
> > It is intended to change such compiler behavior in the future? It is
> incompatible with Delphi and moreover it force us to break the
> encapsulation of the Generic types.
>
> I can't answer this without you providing an example that fails.
>

Sorry for the noise. Some of my classes were bad designed. They look like
this sample (Delphi XE 6 compiles):

 CODE BEGIN 

unit sample;

{$MODE delphi}

interface

type
  TGenericRecord = record
  strict private
Interf: IInterface;
type
  TMockIntfObject = record // Nested generic declaration
  end;

  public
FValue: T;
procedure SetValue(Value: T);
  end;

implementation

{ TGenericRecord }

procedure TGenericRecord.SetValue(Value: T);
begin
  Interf := TMockIntfObject.Create;
end;

end.


 END 


 With fpc i got the error "Fatal: Declation of generic class inside another
generic class is not allowed".

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and Scopes

[Sven Barth]

Am 07.11.2016 15:58 schrieb "African Wild Dog" :
> It is intended to change such compiler behavior in the future? It is
incompatible with Delphi and moreover it force us to break the
encapsulation of the Generic types.

I can't answer this without you providing an example that fails.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and Scopes

[Michael Van Canneyt]

On Mon, 7 Nov 2016, African Wild Dog wrote:


Hello,

I have tried to compile some delphi projects using the latest FPC (3.0.0)
release, and i got several errors related to Ggenerics feature. Reading the
FPC documentation (section 8.8 - A Word About Scope) i have found that FPC
requires that all external types and procedures used in the the Generic
type implementation must be visible when the Generic type is specialized.

It is intended to change such compiler behavior in the future? It is
incompatible with Delphi and moreover it force us to break the
encapsulation of the Generic types.


It may well be that this part of the text is no longer valid. 
Sven Barth would need to look at it to see if it is still so.



Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics and Scopes

[African Wild Dog]

Hello,

I have tried to compile some delphi projects using the latest FPC (3.0.0)
release, and i got several errors related to Ggenerics feature. Reading the
FPC documentation (section 8.8 - A Word About Scope) i have found that FPC
requires that all external types and procedures used in the the Generic
type implementation must be visible when the Generic type is specialized.

It is intended to change such compiler behavior in the future? It is
incompatible with Delphi and moreover it force us to break the
encapsulation of the Generic types.

Best regards
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics: constructor restriction fail

[silvioprog]

On Tue, Nov 11, 2014 at 7:08 PM, Chriss Kalogeropoulos <
iz.iznog...@gmail.com> wrote:

> Hi all,
>
> I am not sure about the constructor case but I consider the FPC
> implementation of generics much more powerful than Delphi's assuming that
> Sven's comment actually works as expected.
> The fact that the method invocation is actually checked on specialization
> and not on declaration means that someone can call methods on the type
> parameter directly and not through some interface restriction which IMO is
> an ugly hack and cancels all possible optimizations for non virtual
> methods, since they much be called through the interface VMT.
> On Delphi XE5 I tried to use an interface constraint so that the compiler
> won't complaint about the methods and then I tried to call them through an
> object variable. This created a compiler internal error, even for class
> methods (declared in the interface but called directly from the type
> parameter). On FPC however it worked and IMO this is a good feature.
>
Recently I have installed Free Pascal 2.7.1 and I got very suprised about
the new implementations in generic structures. I'm even thinking about
rewriting some of my classes to reuse those resources to the fullest.

I'm excited about the Free Pascal 2.8. I want to teach an advanced course
of Object Pascal here in Brazil, and the Free Pascal will be the leading
actor at this story. =)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics: constructor restriction fail

[Chriss Kalogeropoulos]

Hi all,

I am not sure about the constructor case but I consider the FPC
implementation of generics much more powerful than Delphi's assuming that
Sven's comment actually works as expected.
The fact that the method invocation is actually checked on specialization
and not on declaration means that someone can call methods on the type
parameter directly and not through some interface restriction which IMO is
an ugly hack and cancels all possible optimizations for non virtual
methods, since they much be called through the interface VMT.
On Delphi XE5 I tried to use an interface constraint so that the compiler
won't complaint about the methods and then I tried to call them through an
object variable. This created a compiler internal error, even for class
methods (declared in the interface but called directly from the type
parameter). On FPC however it worked and IMO this is a good feature.

Thanks,
Chriss
Στις 11 Νοε 2014 10:54 μ.μ., ο χρήστης "silvioprog" 
έγραψε:

> On Sat, Nov 1, 2014 at 9:04 AM, Sven Barth 
> wrote:
>
>> On 31.10.2014 00:04, silvioprog wrote:
>>
>>> Hello,
>>>
>>> Following this article:
>>>
>>> http://alex.ciobanu.org/?p=51
>>>
>>> The compiler does not check the constructor restriction.
>>>
>>> Try this test:
>>>
>>> {$mode delphi}
>>>
>>>TTest = class
>>>private // hidding the constructor to cause a compiler error
>>>  constructor Create;
>>>end;
>>>
>>>TGen = class
>>>end;
>>>
>>> constructor TTest.Create;
>>> begin
>>> end;
>>>
>>> var  Gen: TGen;
>>> begin
>>>Gen := TGen.Create;
>>> end;
>>>
>>> It compiles well in FPC (from trunk), but the same code in XE is:
>>>
>>> "[dcc32 Error] Unit1.pas(36): E2513 Type parameter 'T' must have one
>>> public parameterless constructor named Create"
>>>
>>> It is a bug in FPC or I need to enable some directive switch?
>>>
>>
>> "constructor" restrictions are not enforced currently, because with the
>> way FPC handles generics compared to Delphi they are a bit useless.
>> Consider this:
>>
>> === code begin ===
>>
>> type
>>   TTest = class
>>   strict private // just to keep it hidden in the same unit
>> constructor Create;
>>   end;
>>
>> var
>>   t: TTest;
>> begin
>>   t := TTest.Create;
>> end.
>>
>> === code end ===
>>
>> The above code snippet will compile, because the compiler will use the
>> next best constructor that it can find which is at least the constructor of
>> TObject.
>>
>> Next snippet:
>>
>> === code begin ===
>>
>> type
>>   TGeneric = class
>> procedure Test;
>>   end;
>>
>> procedure TGeneric.Test;
>> begin
>>   Writeln(T.Bar);
>> end;
>>
>> begin
>> end.
>>
>> === code end ===
>>
>> This will correctly compile in FPC, but not in Delphi, because FPC
>> handles quite some type checking at specialization time not at declaration
>> time. So this will fail to specialize (at compile time) if T does not
>> implement a class method called "Bar".
>>
>> Now let's put these two concepts together and exchange "T.Bar" with
>> "T.Create" (and change the "Writeln" to something else of course ;) ) and
>> it will still compile as long as T provides a Create method. Now as long T
>> is a class this will always be the case, because there is at least the
>> TObject constructor.
>>
>
> Indded. Thanks for the explanation brother. =)
>
>
>> That's why the "constructor" constraint is currently not handled in
>> anyway. That said there'd still be a usecase for this to ensure that there
>> is a default constructor in the class. Also it might be worthwhile to
>> rethink the type checking in case of mode Delphi for generics... :/
>>
>
> It seems good to check it like Delphi em mode delphi, keeping the
> compatibility. =/
>
> --
> Silvio Clécio
> My public projects - github.com/silvioprog
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics: constructor restriction fail

[silvioprog]

On Sat, Nov 1, 2014 at 9:04 AM, Sven Barth 
wrote:

> On 31.10.2014 00:04, silvioprog wrote:
>
>> Hello,
>>
>> Following this article:
>>
>> http://alex.ciobanu.org/?p=51
>>
>> The compiler does not check the constructor restriction.
>>
>> Try this test:
>>
>> {$mode delphi}
>>
>>TTest = class
>>private // hidding the constructor to cause a compiler error
>>  constructor Create;
>>end;
>>
>>TGen = class
>>end;
>>
>> constructor TTest.Create;
>> begin
>> end;
>>
>> var  Gen: TGen;
>> begin
>>Gen := TGen.Create;
>> end;
>>
>> It compiles well in FPC (from trunk), but the same code in XE is:
>>
>> "[dcc32 Error] Unit1.pas(36): E2513 Type parameter 'T' must have one
>> public parameterless constructor named Create"
>>
>> It is a bug in FPC or I need to enable some directive switch?
>>
>
> "constructor" restrictions are not enforced currently, because with the
> way FPC handles generics compared to Delphi they are a bit useless.
> Consider this:
>
> === code begin ===
>
> type
>   TTest = class
>   strict private // just to keep it hidden in the same unit
> constructor Create;
>   end;
>
> var
>   t: TTest;
> begin
>   t := TTest.Create;
> end.
>
> === code end ===
>
> The above code snippet will compile, because the compiler will use the
> next best constructor that it can find which is at least the constructor of
> TObject.
>
> Next snippet:
>
> === code begin ===
>
> type
>   TGeneric = class
> procedure Test;
>   end;
>
> procedure TGeneric.Test;
> begin
>   Writeln(T.Bar);
> end;
>
> begin
> end.
>
> === code end ===
>
> This will correctly compile in FPC, but not in Delphi, because FPC handles
> quite some type checking at specialization time not at declaration time. So
> this will fail to specialize (at compile time) if T does not implement a
> class method called "Bar".
>
> Now let's put these two concepts together and exchange "T.Bar" with
> "T.Create" (and change the "Writeln" to something else of course ;) ) and
> it will still compile as long as T provides a Create method. Now as long T
> is a class this will always be the case, because there is at least the
> TObject constructor.
>

Indded. Thanks for the explanation brother. =)


> That's why the "constructor" constraint is currently not handled in
> anyway. That said there'd still be a usecase for this to ensure that there
> is a default constructor in the class. Also it might be worthwhile to
> rethink the type checking in case of mode Delphi for generics... :/
>

It seems good to check it like Delphi em mode delphi, keeping the
compatibility. =/

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics: constructor restriction fail

[Sven Barth]

On 31.10.2014 00:04, silvioprog wrote:

Hello,

Following this article:

http://alex.ciobanu.org/?p=51

The compiler does not check the constructor restriction.

Try this test:

{$mode delphi}

   TTest = class
   private // hidding the constructor to cause a compiler error
 constructor Create;
   end;

   TGen = class
   end;

constructor TTest.Create;
begin
end;

var  Gen: TGen;
begin
   Gen := TGen.Create;
end;

It compiles well in FPC (from trunk), but the same code in XE is:

"[dcc32 Error] Unit1.pas(36): E2513 Type parameter 'T' must have one
public parameterless constructor named Create"

It is a bug in FPC or I need to enable some directive switch?


"constructor" restrictions are not enforced currently, because with the 
way FPC handles generics compared to Delphi they are a bit useless. 
Consider this:


=== code begin ===

type
  TTest = class
  strict private // just to keep it hidden in the same unit
constructor Create;
  end;

var
  t: TTest;
begin
  t := TTest.Create;
end.

=== code end ===

The above code snippet will compile, because the compiler will use the 
next best constructor that it can find which is at least the constructor 
of TObject.


Next snippet:

=== code begin ===

type
  TGeneric = class
procedure Test;
  end;

procedure TGeneric.Test;
begin
  Writeln(T.Bar);
end;

begin
end.

=== code end ===

This will correctly compile in FPC, but not in Delphi, because FPC 
handles quite some type checking at specialization time not at 
declaration time. So this will fail to specialize (at compile time) if T 
does not implement a class method called "Bar".


Now let's put these two concepts together and exchange "T.Bar" with 
"T.Create" (and change the "Writeln" to something else of course ;) ) 
and it will still compile as long as T provides a Create method. Now as 
long T is a class this will always be the case, because there is at 
least the TObject constructor.


That's why the "constructor" constraint is currently not handled in 
anyway. That said there'd still be a usecase for this to ensure that 
there is a default constructor in the class. Also it might be worthwhile 
to rethink the type checking in case of mode Delphi for generics... :/


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics: constructor restriction fail

[silvioprog]

Hello,

Following this article:

http://alex.ciobanu.org/?p=51

The compiler does not check the constructor restriction.

Try this test:

{$mode delphi}

  TTest = class
  private // hidding the constructor to cause a compiler error
constructor Create;
  end;

  TGen = class
  end;

constructor TTest.Create;
begin
end;

var  Gen: TGen;
begin
  Gen := TGen.Create;
end;

It compiles well in FPC (from trunk), but the same code in XE is:

"[dcc32 Error] Unit1.pas(36): E2513 Type parameter 'T' must have one public
parameterless constructor named Create"

It is a bug in FPC or I need to enable some directive switch?

Thank you!

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Syntax

[Michael Schnell]

On 02/27/2014 11:41 PM, silvioprog wrote:


that wonderful unit!


Any chance to include it in the fpc svn ?

-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Syntax

[Fabrício Srdic]

Thanks for clarifying!


2014-02-27 21:34 GMT-03:00 leledumbo :

> FPC supports both Delphi and its own generics syntax. Nothing needs to be
> changed, but maybe FPC one will be enhanced more (it's already enhanced a
> lot since latest stable).
>
>
>
> --
> View this message in context:
> http://free-pascal-general.1045716.n5.nabble.com/Generics-Syntax-tp5718453p5718456.html
> Sent from the Free Pascal - General mailing list archive at Nabble.com.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Syntax

[leledumbo]

FPC supports both Delphi and its own generics syntax. Nothing needs to be
changed, but maybe FPC one will be enhanced more (it's already enhanced a
lot since latest stable).



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Generics-Syntax-tp5718453p5718456.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Syntax

[silvioprog]

2014-02-27 19:36 GMT-03:00 Fabrício Srdic :

> Hello,
>
> Will the generics syntax change in the fpc 2.8?
>
> The fpc-generics-collection library (
> http://forum.lazarus.freepascal.org/index.php?topic=20965.0) doesn't use
> the "generic" keyword to declare a generic class, which seems to be a more
> delphi-like way. It requires the  fpc 2.7.1.
>
> Thanks
>

:o

that wonderful unit!

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics Syntax

[Fabrício Srdic]

Hello,

Will the generics syntax change in the fpc 2.8?

The fpc-generics-collection library (
http://forum.lazarus.freepascal.org/index.php?topic=20965.0) doesn't use
the "generic" keyword to declare a generic class, which seems to be a more
delphi-like way. It requires the  fpc 2.7.1.

Thanks
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and key words

[Maciej Izak]

>  Currently only in mode Delphi.
>
> Regards,
> Sven
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

also "generics overload" (TA, TA) don't work in objfpc... the
main reason why objfpc is unusable for me (also because "generic" and
"specialize" keyword)...

>.<

Regards,
Maciej Izak (hnb)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and key words

[silvioprog]

2014-02-13 5:43 GMT-02:00 Sven Barth :

> Am 13.02.2014 01:28, schrieb silvioprog:
>
>> Hello,
>>
>> Can I use it:
>>
>> TBrookAction = class(TBrookObject)
>> ...
>>
>> instead of?:
>>
>> generic TBrookAction = class(TBrookObject)
>> ...
>>
>> And, can I use it:
>>
>> TPersonAction = class(TBrookAction)
>> ...
>>
>> instead of?:
>>
>> TPersonAction = class(specialize TBrookAction)
>> ...
>>
>> This would save typing.
>>
>> Sorry, I'm beginner in generics.
>>
>>  Currently only in mode Delphi.
>
> Regards,
> Sven


Thank you Sven!

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics and key words

[Sven Barth]

Am 13.02.2014 01:28, schrieb silvioprog:

Hello,

Can I use it:

TBrookAction = class(TBrookObject)
...

instead of?:

generic TBrookAction = class(TBrookObject)
...

And, can I use it:

TPersonAction = class(TBrookAction)
...

instead of?:

TPersonAction = class(specialize TBrookAction)
...

This would save typing.

Sorry, I'm beginner in generics.


Currently only in mode Delphi.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics and key words

[silvioprog]

Hello,

Can I use it:

TBrookAction = class(TBrookObject)
...

instead of?:

generic TBrookAction = class(TBrookObject)
...

And, can I use it:

TPersonAction = class(TBrookAction)
...

instead of?:

TPersonAction = class(specialize TBrookAction)
...

This would save typing.

Sorry, I'm beginner in generics.

-- 
Silvio Clécio
My public projects - github.com/silvioprog
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics - how to rewrite TOjectDictionary

[Sven Barth]

Am 07.04.2013 23:09 schrieb "Dimitri Smits" :
>
> Hi,
>
> Ever tried TStringList with Strings[] and Objects[] properties?

The speciality of TObjectDirectory is that it frees the objects when an
entry is deleted (similar to TObjectList).
But I now remember that we added an OwnsObjects property to TStringList
some time ago...

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics - how to rewrite TOjectDictionary

[Dimitri Smits]

Hi,

Ever tried TStringList with Strings[] and Objects[] properties?

kind regards,
Dimitri Smits


- Oorspronkelijk e-mail -
> Van: "Marius" 
> Aan: fpc-pascal@lists.freepascal.org
> Verzonden: Zondag 7 april 2013 18:48:02
> Onderwerp: [fpc-pascal] Generics - how to rewrite TOjectDictionary
> 
> Hello,
> 
> It was many years ago i tried fpc/lazarus so i'm not up to speed with
> eveything. At this moment I'm trying to rewrite a piece of software
> from
> delphi to fpc/laz and i'm having trouble rewriting generics and in
> special
> the TObjectDictionary. Below shows how it is implemented in delphi.
> 
> Is there a native fpc solution for this and if there is not what are
> the
> alternatives to rewrite this? Or would it even be better to avoid
> generics
> in general?
> 
> TMyDic = TObjectDictionary ;
> 
> I would welcome any tips to solve this
> 
> Thanks,
> Marius
> 
> 
> I'm using fpc 2.7.1, laz 1.1(svn 4/7/13)
> 
> 
> 
> 
> --
> View this message in context:
> http://free-pascal-general.1045716.n5.nabble.com/Generics-how-to-rewrite-TOjectDictionary-tp5714029.html
> Sent from the Free Pascal - General mailing list archive at
> Nabble.com.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics - how to rewrite TOjectDictionary

[Marius]

Hello,

It was many years ago i tried fpc/lazarus so i'm not up to speed with
eveything. At this moment I'm trying to rewrite a piece of software from
delphi to fpc/laz and i'm having trouble rewriting generics and in special
the TObjectDictionary. Below shows how it is implemented in delphi. 

Is there a native fpc solution for this and if there is not what are the
alternatives to rewrite this? Or would it even be better to avoid generics
in general?

TMyDic = TObjectDictionary ;

I would welcome any tips to solve this

Thanks,
Marius


I'm using fpc 2.7.1, laz 1.1(svn 4/7/13)




--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Generics-how-to-rewrite-TOjectDictionary-tp5714029.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Compile Error, 2.4.2 vs 2.6.0

[David Copeland]

Thanks very much. It now compiles! 

Dave.




-Original Message-
From: J.-c. Chu 
Reply-to: FPC-Pascal users discussions 
To: FPC-Pascal users discussions 
Subject: Re: [fpc-pascal] Generics Compile Error, 2.4.2 vs 2.6.0
Date: Tue, 14 Feb 2012 00:59:03 +0800

If you are compiling the unit in Delphi mode, you’ll need to use the
syntax of Delphi.

*  Generics are defined without the GENERIC keyword.
*  Generics are specialized without the SPECIALIZE keyword.
*  To define class-local types and variables, visibility specifiers need
   to be placed before the TYPE and VAR keywords.
*  Implementations of the methods of a generic class must include the
   type parameters of the class.

Please check if the attached file works.





___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Compile Error, 2.4.2 vs 2.6.0

[J.-c. Chu]

If you are compiling the unit in Delphi mode, you’ll need to use the
syntax of Delphi.

*  Generics are defined without the GENERIC keyword.
*  Generics are specialized without the SPECIALIZE keyword.
*  To define class-local types and variables, visibility specifiers need
   to be placed before the TYPE and VAR keywords.
*  Implementations of the methods of a generic class must include the
   type parameters of the class.

Please check if the attached file works.


On February 14, 2012, David Copeland wrote:

> Under FPC 2.4.2 I have been using RBTree unit that uses generics. With
> 2.6.0 it fails to compile. I know that there have been changes for 2.6.0
> but I have checked the syntax in the 2.6.0 Language Reference and cannot
> see why the error is occurring. I have also looked in Mantis but don't
> know if anything there relates to my problem. I have excerpted the code
> below and attached the complete unit.
> 
> ==
> 
> unit FOS_REDBLACKTREE_GEN;
> 
> // (c) Copyright FirmOS Business Solutions GmbH
> // Author Helmut Hartl, Franz Schober
> 
> }
> //{$MODE OBJFPC}
> {$MODE DELPHI}
> {$H+}
> 
> interface
> 
> type
>   TRB_NodeColor=(R,B);
> 
>   { TGFOS_RBTree }
>   {$B-}
>   generic TGFOS_RBTree<_TKey,_TStore> = class(TInterfacedObject)
> 
> *** The error occurs at the line above.
> 
> Free Pascal Compiler version 2.6.0 [2012/02/08] for x86_64
> Copyright (c) 1993-2011 by Florian Klaempfl and others
> Target OS: Linux for x86-64
> Compiling FOS_REDBLACKTREE_GEN.pas
> FOS_REDBLACKTREE_GEN.pas(48,11) Fatal: Syntax error, "=" expected but
> "identifier TGFOS_RBTREE" found
> Fatal: Compilation aborted
> 
> 
> type public
>   PFOS_RB_NodeG=^TFOS_RB_NodeG;
>   _PStore   =^_TStore;
>   TFOS_RB_NodeG = packed record
>   k:  _TKey;
>   left, right, parent: PFOS_RB_NodeG;
>   col: TRB_NodeColor;
>   val:_TStore;
>end;
>TCompareKeys = function  (const Item1, Item2: _TKey):
> Integer;
>TGUndefined  = function  :_Tstore;
>TGUndefinedKey   = function  :_TKey;
>TGFOS_RB_OnItem  = procedure (const Item:_TStore) of object;
>TGFOS_RB_OnItemN = procedure (const Item:_TStore);
> 
> 
> ==
> 
> Thanks for any help.
> 
> 
> 
> 
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

-- 
Best Regards,
J.-c. Chu
unit FOS_REDBLACKTREE_GEN;

// (c) Copyright FirmOS Business Solutions GmbH
// Author Helmut Hartl, Franz Schober

{ // New Style BSD Licence (OSI)

Copyright (c) 2001-2009, FirmOS Business Solutions GmbH
All rights reserved.

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice,
  this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
* Neither the name of the  nor the names
  of its contributors may be used to endorse or promote products derived
  from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

}
//{$MODE OBJFPC}
{$MODE DELPHI}
{$H+}

interface

type
  TRB_NodeColor=(R,B);

  { TGFOS_RBTree }
  {$B-}
  TGFOS_RBTree<_TKey,_TStore> = class(TInterfacedObject)
  public
type
  PFOS_RB_NodeG=^TFOS_RB_NodeG;
  _PStore   =^_TStore;
  TFOS_RB_NodeG = packed record
  k:  _TKey;
  left, right, parent: PFOS_RB_NodeG;
  col: TRB_NodeColor;
  val:_TStore;
   end;
   TCompareKeys = function  (const Item1, Item2: _TKey): Integer;
   TGUndefined  = function  :_Tstore;
   TGUndefinedKey   = function  :_TKey;
   TGFOS_RB_OnItem  = procedure (const Item:_TStore) of object;
   TGFOS_RB_OnItemN = procedure (const Item:_TStore);
  private
var
  _Count:QWord;
  _Compare:  TCompareKeys;
  _Undef:TGUndefined;
  _UndefKey: TGUndefinedK

[fpc-pascal] Generics and Mac

[Juha Manninen]

I used generics in Lazarus code base for the first time, in TreeFilter
component:

  TTreeNodeList = specialize TFPGList;
and
  TBranchList = specialize TFPGObjectList;

I works for me on Windows and Linux, with FPC 2.4.4 and 2.6.0 RC1.
Now Zeljan reported it does not compile on Mac OSX 64-bit, using FPC 2.6.0
RC1.
What can cause it? My generics usage is the most basic possible.
Both TTreeNode and TBranch are simple classes.

Juha
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[Graeme Geldenhuys]

On 9 November 2011 22:08, Michael Van Canneyt  wrote:
>
> Hm. I fail to see this: Where is the gain in that ?


+1



-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[Michael Van Canneyt]

On Wed, 9 Nov 2011, tcoq wrote:


It's also possible to create a generic descendent of TCollection, where the 
only duplicated code is the property override. This is probably the best of 
both worlds: reusing the TCollection while moving to generics.


Hm. I fail to see this: Where is the gain in that ?

Michael.


Best regards
Thierry
- Mail Original -
De: "michael vancanneyt" 
À: "FPC-Pascal users discussions" 
Envoyé: Mardi 8 Novembre 2011 13h22:31 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [fpc-pascal] Generics vs TCollection


...
The difference is mainly that in the case of TCollection(Item) you need to
override the items property; With generics, you can skip this step.
At the expense of copying the whole TCollection code each time you create a
specialized descendent.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[Felipe Monteiro de Carvalho]

In my experience generics are very good, but they are not without
problems. There are some limitations in the implementation and I have
already hit some bumps in the road when using them (search the
mailling list, I don't remember exactly the issues)

But I can't compare them to collections, because I never use them
except in the LCL parts that use them, my favorites are TFPList, and
the generic equivalent (TFPGList or something like that).

-- 
Felipe Monteiro de Carvalho
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[tcoq]

It's also possible to create a generic descendent of TCollection, where the 
only duplicated code is the property override. This is probably the best of 
both worlds: reusing the TCollection while moving to generics.
Best regards
Thierry
- Mail Original -
De: "michael vancanneyt" 
À: "FPC-Pascal users discussions" 
Envoyé: Mardi 8 Novembre 2011 13h22:31 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [fpc-pascal] Generics vs TCollection


...
The difference is mainly that in the case of TCollection(Item) you need to
override the items property; With generics, you can skip this step.
At the expense of copying the whole TCollection code each time you create a
specialized descendent.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[michael . vancanneyt]

On Tue, 8 Nov 2011, Graeme Geldenhuys wrote:


On 8 November 2011 12:13,   wrote:


I have tons of code that uses them. Lazarus has tons of code that uses them.
There is no way that we're going to rewrite all that stuff.


Sorry for any confusion. I did not post this with the intention of
removing TCollection/TCollectionItem classes from FPC. I'm simply
asking from a functionality point of view. Can Generics replace the
usage of TCollection/TCollectionItem in all cases? Purely from a
functionality point of view, it seems like it should be possible - but
I know nothing of Generics (never used them).


You should see it differently: there is a generics collection which 
performs the same function as TCollection/TCollectionitem.


The difference is mainly that in the case of TCollection(Item) you need to
override the items property; With generics, you can skip this step.
At the expense of copying the whole TCollection code each time you create a
specialized descendent.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[Graeme Geldenhuys]

On 8 November 2011 11:58, Jonas Maebe > wrote:
>
> At the very least, backward compatibility with existing code. We even still
> ship a Turbo Pascal-compatible "objects" unit.


Please see my reply to Michael. I had no intentions in recommending
the removal of TCollection. I'm just comparing functionality of
Generics with TCollection.


-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[Graeme Geldenhuys]

On 8 November 2011 12:13,   wrote:
>
> I have tons of code that uses them. Lazarus has tons of code that uses them.
> There is no way that we're going to rewrite all that stuff.

Sorry for any confusion. I did not post this with the intention of
removing TCollection/TCollectionItem classes from FPC. I'm simply
asking from a functionality point of view. Can Generics replace the
usage of TCollection/TCollectionItem in all cases? Purely from a
functionality point of view, it seems like it should be possible - but
I know nothing of Generics (never used them).

I know Lazarus IDE uses TCollection in many property editors. Could
Generics even replace those use cases too? I guess this might be
better asked in the Lazarus mailing list.


-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[michael . vancanneyt]

On Tue, 8 Nov 2011, Graeme Geldenhuys wrote:


Hi,

I was reviewing some old code that used TCollection & TCollectionItem
descendants. This made me think... With the introduction of Generics,
is there really still a need for TCollection/TCollectionItem?



I have tons of code that uses them. Lazarus has tons of code that uses them.
There is no way that we're going to rewrite all that stuff.

So: yes, even if only for backwards compatibility.

Nothing stops people from not using it, and use generics instead, if they
are so inclined.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics vs TCollection

[Jonas Maebe]

On 08 Nov 2011, at 10:55, Graeme Geldenhuys wrote:


I was reviewing some old code that used TCollection & TCollectionItem
descendants. This made me think... With the introduction of Generics,
is there really still a need for TCollection/TCollectionItem?


At the very least, backward compatibility with existing code. We even  
still ship a Turbo Pascal-compatible "objects" unit.



Jonas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics vs TCollection

[Graeme Geldenhuys]

Hi,

I was reviewing some old code that used TCollection & TCollectionItem
descendants. This made me think... With the introduction of Generics,
is there really still a need for TCollection/TCollectionItem?

-- 
Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics question

[Sven Barth]

I have not yet looked at the parsing of methods of generic classes 
during my work on the generics, but when I'll implement generic methods 
I'll try to take a look at your problem.


Regards,
Sven


On 12.05.2011 12:37, Adrian Veith wrote:

Hi,

I try this:

type
   TTestGen  = class
 constructor Create();
 class function Test(val: T): string; inline;
   end;


function Blah(const val: Integer): string; inline; overload;
begin
   Result:= IntToStr(val + 1);
end;

function Blah(const val: string): string; inline; overload;
begin
   Result:= val + '1';
end;

{ TTestGen }

constructor TTestGen.Create();
begin
end;

class function TTestGen.Test(val: T): string;
begin
   Result:= Blah(val);
end;


type
   TTestInt = TTestGen;
   TTestString = TTestGen;

and get an error: can't determin which overloaded function Blah to use.

It would be nice if this could work. It would be a way to inject inline
functions into a generic class - avoiding virtual functions.

BTW. If I only have one Blah and only one corresponding specialization
it works.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] generics question

[Adrian Veith]

Hi,

I try this:

type
  TTestGen = class
constructor Create();
class function Test(val: T): string; inline;
  end;


function Blah(const val: Integer): string; inline; overload;
begin
  Result:= IntToStr(val + 1);
end;

function Blah(const val: string): string; inline; overload;
begin
  Result:= val + '1';
end;

{ TTestGen }

constructor TTestGen.Create();
begin
end;

class function TTestGen.Test(val: T): string;
begin
  Result:= Blah(val);
end;


type
  TTestInt = TTestGen;
  TTestString = TTestGen; 

and get an error: can't determin which overloaded function Blah to use.

It would be nice if this could work. It would be a way to inject inline
functions into a generic class - avoiding virtual functions.

BTW. If I only have one Blah and only one corresponding specialization
it works.

Cheers,

Adrian.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics feature status

[Sven Barth]

On 30.04.2011 03:15, Paul Ishenin wrote:

30.04.2011 3:28, leledumbo wrote:

I see now that generics have improved a lot since latest release, we even
have Delphi compatible syntax in Delphi mode. Recursive generic type is
supported as well now (finally, I can continue my data structure library
:)). Seeing these facts, what's the status of this feature now? Is it
considered stable?--

No, they are not stable. FPC generic syntax may change. But you can rely
on delphi syntax (as we can't change it) with few limitations at the
moment:
- no multiply generics with the same identifier and different amount of
type parameters [1],
- no generic methods,
- no type constraints.

Also I may forgot something.

About [1] - in delphi it is possible to define different generics with
the same identifier and different amount of type parameteres (even in
the same unit). E.g.
TList = class ...; TList = class ...; TList = class ...;

Then you can declare variables with any of that types. E.g.
var
L: TList;
LI: TList;
LIO: TList

As I know Sven will work to support this and other missing generics
features.


Point 1 is already on a good way - with backwards compatible FPC syntax 
:) The only thing that still scares me are those nasty inline 
declarations -.-


Type constraints (at least non-interface ones) should be rather easy to 
do. The hardest part might be the parsing.


Regarding generic methods: I've already found the points where I'll need 
to hook in and keep those in mind while extending/adjusting the existing 
code, but that's it currently.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics feature status

[Paul Ishenin]

30.04.2011 3:28, leledumbo wrote:

I see now that generics have improved a lot since latest release, we even
have Delphi compatible syntax in Delphi mode. Recursive generic type is
supported as well now (finally, I can continue my data structure library
:)). Seeing these facts, what's the status of this feature now? Is it
considered stable?--
No, they are not stable. FPC generic syntax may change. But you can rely 
on delphi syntax (as we can't change it) with few limitations at the moment:
 - no multiply generics with the same identifier and different amount 
of type parameters [1],

 - no generic methods,
 - no type constraints.

Also I may forgot something.

About [1] - in delphi it is possible to define different generics with 
the same identifier and different amount of type parameteres (even in 
the same unit). E.g.

TList = class ...; TList = class ...; TList = class ...;

Then you can declare variables with any of that types. E.g.
var
  L: TList;
  LI: TList;
  LIO: TList

As I know Sven will work to support this and other missing generics 
features.


Best regards,
Paul Ishenin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics feature status

[Anthony Walter]

Is this true? I'd really like to see generics that with a mode where it is
possible to say with the following syntax (compatible with Delphi):

type
  IDelegate = interface
procedure Add(const Handler: T);
procedure Remove(const Handler: T);
  end;

And then specialize using the following syntax:

type
  INotifyDelegate = IDelegate;

Also, generic constraints are needed:

type
  TComponentTool = class(TObject)
  public
procedure DoSomething(const C: T);
  end;

On Fri, Apr 29, 2011 at 3:28 PM, leledumbo wrote:

> I see now that generics have improved a lot since latest release, we even
> have Delphi compatible syntax in Delphi mode. Recursive generic type is
> supported as well now (finally, I can continue my data structure library
> :)). Seeing these facts, what's the status of this feature now? Is it
> considered stable?--
> View this message in context:
> http://free-pascal-general.1045716.n5.nabble.com/Generics-feature-status-tp4359580p4359580.html
> Sent from the Free Pascal - General mailing list archive at Nabble.com.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics feature status

[leledumbo]

I see now that generics have improved a lot since latest release, we even
have Delphi compatible syntax in Delphi mode. Recursive generic type is
supported as well now (finally, I can continue my data structure library
:)). Seeing these facts, what's the status of this feature now? Is it
considered stable?--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Generics-feature-status-tp4359580p4359580.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics in Delphi mode?

[Jonas Maebe]

On 30 Mar 2011, at 21:28, Tim Veldhuizen wrote:

> Wonderful! I can hardly wait for it to be released in a stable
> version. I have version 2.4.0 here as the default freepascal package
> in Fedora 13, but I'll give the new release a spin as soon as it's
> out. I don't see a release date announcement anywhere though. Guess
> we'll have to be patient..

It won't be in the next stable release (2.4.4), but only in the next major 
release (2.6.0). There is no date yet for the latter.


Jonas___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics in Delphi mode?

[Tim Veldhuizen]

Hi,

2011/3/30 Žilvinas Ledas 
> It is already implemented in Trunk ;)

Wonderful! I can hardly wait for it to be released in a stable
version. I have version 2.4.0 here as the default freepascal package
in Fedora 13, but I'll give the new release a spin as soon as it's
out. I don't see a release date announcement anywhere though. Guess
we'll have to be patient..

Thanks!
Tim.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics in Delphi mode?

[Žilvinas Ledas]

Hi,

On 2011-03-30 21:59, timveldhuizen wrote:

I hope very much that this will be changed to a delphi compatible style

It is already implemented in Trunk ;)


Regards,
Žilvinas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Generics in Delphi mode?

[timveldhuizen]

Hi. I just found out today that generics also work in Free Pascal (and as I
understand it, it was even implemented before it was added in delphi :) ).

However, the way it was implemented makes me frown a bit. Not that it is
that bad or unusable or illogical, but as I use Delphi mode, I was expecting
it to be compatible to the way it works in delphi. In other words: with the
same syntax and same generic types like TList and TObjectList etc... Now I
still have to add a number of $IFDEF's everywhere to make it compatible with
delphi even though I i've used:

{$IFDEF FPC}
  {$MODE DELPHI}
{$ENDIF}

I hope very much that this will be changed to a delphi compatible style,
because if even the delphi compatible mode starts to deviate from delphi,
then how far will the compatibility mode implementation be from the
Embarcadero delphi language spec in something like 5 years from now?

Greetz,
Tim.

--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Generics-in-Delphi-mode-tp4272087p4272087.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[David Emerson]

> @David: Maybe you can restructure your class hierarchy to something like 
> this (you'll need to be a bit creative here ^^):

heh, no, my solution is to abandon generics :-) I used a find/replace script to 
make alternate classes with real values. Thanks for all your input, though. 
Thanks to you, too, Honza

~David.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[Honza]

2010/12/19 Sven Barth :
> While I DO agree with you (after some thinking about the consequences) that
> a base class should not be allowed to be specified by a template parameter
> (and this is the way it already is), I don't agree with you that the
> documentation states this as clearly as you propose it.

I admit, that it looks clear to me only now - after/because of several
hours bouncing my head against the keyboard when I struggled to get
generics make what I wanted, so I'm not anymore unbiased when looking
at the docs :-)

> Here the documentation of generics should state more clearly that "class(T)"
> is not allowed, neither in the main class nor in sub classes.

I believe any reasonable improvement patch of the docs would be
welcome by the dev team. You can then get into the chapter text
exactly those words you would like to read there - a nice compensation
for a little effort I think :-)

Best regards,

-- 
bflm
freepascal-bits.blogspot.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[Sven Barth]

On 19.12.2010 13:03, Honza wrote:

2010/12/19 Sven Barth:

"There is a single placeholder _T. It will be substituted by a type
identifier when the generic class is specialized. The identifier _T
*may not be used for anything else than a placehoder*. "



According to the documentation I'd say that it should succeed, because in
"class(BaseClass)" "BaseClass" is a type identifier. But of course that has
its own set of problems... see the second last paragraph of this mail.

The type parameter in the inheritance part clause, i.e. class(T) part
of the generic class declaration has nothing to do with the
placeholder formal parameter. The placeholder formal arg list are
given inside the sharp brackets<>  as a kind of macro parameters. And
the docs explicitly states that a placeholder identifier may not be
used elsewhere in the generic declaration except for identifying the
place where the "macro" expansion should substitute the
instantiation/specialization parameter. So using it in the inheritance
clause is invalid. IMO the docs are clear on this and my experiments
seems to confirm this behaviour. I have excersised generics a lot to
get heLib compiled and working. Still the latest changes in the
compiler broke the published code as I realized very recently and not
yet uploaded the remedy which sits on my local disk.



While I DO agree with you (after some thinking about the consequences) 
that a base class should not be allowed to be specified by a template 
parameter (and this is the way it already is), I don't agree with you 
that the documentation states this as clearly as you propose it.


The documentation says that every occurrence of a template parameter 
will be replaced by a type identifier (e.g. Integer, String, TObject). 
Now the documentation of a normal class declaration ( 
http://www.freepascal.org/docs-html/ref/refse31.html#x67-770006.1 ) 
states that the heritage clause contains a "class type identifier" which 
is just a special case of a type identifier.
So when one reads the documentation of generics one CAN (!) come to the 
(wrong) conclusion that you can also put a template parameter into the 
heritage clause of a class.


Here the documentation of generics should state more clearly that 
"class(T)" is not allowed, neither in the main class nor in sub classes.



I'm still thinking how David's idea could be achieved in another way which
is supported by the compiler...


I've not yet got time to look at his goal at all, so I don't know. I
just spotted the invalid constructs presented.



@David: Maybe you can restructure your class hierarchy to something like 
this (you'll need to be a bit creative here ^^):


  generic gt_box<_num> = class
type
  t_point = specialize gt_point<_num>;
var
  f_position: t_point;
  f_width, f_height : _num;
end;

or this

  generic gt_box<_t_point, _num> = class
f_position: _t_point;
f_width, f_height: _num;
  end;

I don't really see another possibility.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[Honza]

2010/12/19 David Emerson :

Please see my just sent  reply to Sven.

-- 
bflm
freepascal-bits.blogspot.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[Honza]

2010/12/19 Sven Barth :
>> "There is a single placeholder _T. It will be substituted by a type
>> identifier when the generic class is specialized. The identifier _T
>> *may not be used for anything else than a placehoder*. "
>>
>
> According to the documentation I'd say that it should succeed, because in
> "class(BaseClass)" "BaseClass" is a type identifier. But of course that has
> its own set of problems... see the second last paragraph of this mail.
The type parameter in the inheritance part clause, i.e. class(T) part
of the generic class declaration has nothing to do with the
placeholder formal parameter. The placeholder formal arg list are
given inside the sharp brackets <> as a kind of macro parameters. And
the docs explicitly states that a placeholder identifier may not be
used elsewhere in the generic declaration except for identifying the
place where the "macro" expansion should substitute the
instantiation/specialization parameter. So using it in the inheritance
clause is invalid. IMO the docs are clear on this and my experiments
seems to confirm this behaviour. I have excersised generics a lot to
get heLib compiled and working. Still the latest changes in the
compiler broke the published code as I realized very recently and not
yet uploaded the remedy which sits on my local disk.

>> The bold part is IMO violated by the declaration. Anyway, it could be
>> perhaps (not tested) written as:
>>
>> type
>>   TBoxProxy = class(_t_point);
>>   generic gt_box<_t_point, _num>  = class(TBoxProxy)
>>     f_width, f_height : _num;
>>   end;
>>
>
> No, this won't work, because "_t_point" won't be defined when "TBoxProxy" is
> parsed.

Yes it's not defined and that was my 3rd note, you can't base a
generic declaration on a not yet specialized ancestor.


>> Another strange point is, that the declaration of gt_box doesn't use
>> the formal specialization paramater `_t_point` at all (in the posted
>> code), so the same the other way around should also work:

> It IS used, because David wants to influence the class the generic class
> gt_box inherits from when specializing the class.

It is not used *anywhere except* in the invalid place of the ancestor type.

> type
>  TIntPoint = class
>    x, y: Integer;
>  end;
>
>  TFloatPoint = class
>    x, y: Single;
>  end;
>
>  generic gt_box<_t_point, _num> = class(_t_point)
>    width, height: _num;
>  end;
>
>  TFloatBox = specialize gt_box;
>  TIntBox = specialize gt_box;
>
>> type
>>   generic gt_box<_num>  = class<_t_point>
>>     f_width, f_height : _num;
>>   end;
>>
>
> This won't compile because of the "<...>" around "_t_point". Also it's not
> what Daniel intends.

Yes, that's just a typo, round parenthesis are what I've meant and
should wrote there.

>> A 3rd note is that your code can't compile as _t_point is not declared
>> when gt_box is declared, but the declaration wants to inherit from
>> _t_point, so IMO also for this the code is rightfully rejected the
>> compiler.
>
> The question is whether this should be rejected if "_t_point" is a template
> parameter... on the other hand this would violate compile time checks of the
> generic class...
>
> I'm still thinking how David's idea could be achieved in another way which
> is supported by the compiler...

I've not yet got time to look at his goal at all, so I don't know. I
just spotted the invalid constructs presented.

-- 
bflm
freepascal-bits.blogspot.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[David Emerson]

On Sat 18 Dec 2010, Honza wrote:
> 2010/12/19 David Emerson :
> > type
> >  generic gt_box<_t_point,_num> = class (_t_point)   // FAILS :-(
> >   f_width, f_height : _num;
> >   end;
> 
> I think it should fail according to the docs, see:
> 
> http://www.freepascal.org/docs-html/ref/refse42.html
> 
> "There is a single placeholder _T. It will be substituted by a type
> identifier when the generic class is specialized. The identifier _T
> *may not be used for anything else than a placehoder*. "

Well, IMO the docs are a bit vague as to the definition of "placeholder". 
However, according to experience:
- a placeholder _can_ be used for a type identifier that is used as a field 
within the class
- a placeholder can't be used for a type identifier that is used to specify the 
ancestor class to inherit from

Maybe "placeholder" is also referring to something that's going on internally 
to 
the compiler -- when the generic is defined, its class structure and VMT and 
everything must be known. I'm no compiler writer, but I guess it makes sense 
from that perspective. I was thinking of "placeholder" from the other 
perspective, in terms of words: the specialization substitutes these words into 
those places, and those places can by any type identifiers. More like what I'd 
expect from e.g. a scripting language. But it doesn't work like that.

> The bold part is IMO violated by the declaration. Anyway, it could be
> perhaps (not tested) written as:
> 
> type
>   TBoxProxy = class(_t_point);
>   generic gt_box<_t_point, _num> = class(TBoxProxy)
> f_width, f_height : _num;
>   end;

no, this is completely not right at all. _t_point is a placeholder. I want to 
use a placeholder to specify the ancestor class. In your example here you're 
treating _t_point as an already-defined class which TBoxProxy can inherit from. 
_t_point doesn't exist, it never exists, it's just a placeholder for a proper 
type identifier.

> Another strange point is, that the declaration of gt_box doesn't use
> the formal specialization paramater `_t_point` at all (in the posted
> code)

yes it does. It is used to specify the ancestor class.
But I think I have now beaten the issue to death.

I am curious, though, if e.g. delphi allows this syntax?

Cheers,
David

> , so the same the other way around should also work: 
> 
> type
>   generic gt_box<_num> = class<_t_point>
> f_width, f_height : _num;
>   end;
> 
> A 3rd note is that your code can't compile as _t_point is not declared
> when gt_box is declared, but the declaration wants to inherit from
> _t_point, so IMO also for this the code is rightfully rejected the
> compiler.
> 
> HTH
> -- 
> bflm
> freepascal-bits.blogspot.com
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> 



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[Sven Barth]

On 19.12.2010 08:34, Honza wrote:

2010/12/19 David Emerson:

type
  generic gt_box<_t_point,_num>  = class (_t_point)   // FAILS :-(
   f_width, f_height : _num;
   end;


I think it should fail according to the docs, see:

http://www.freepascal.org/docs-html/ref/refse42.html

"There is a single placeholder _T. It will be substituted by a type
identifier when the generic class is specialized. The identifier _T
*may not be used for anything else than a placehoder*. "



According to the documentation I'd say that it should succeed, because 
in "class(BaseClass)" "BaseClass" is a type identifier. But of course 
that has its own set of problems... see the second last paragraph of 
this mail.



The bold part is IMO violated by the declaration. Anyway, it could be
perhaps (not tested) written as:

type
   TBoxProxy = class(_t_point);
   generic gt_box<_t_point, _num>  = class(TBoxProxy)
 f_width, f_height : _num;
   end;



No, this won't work, because "_t_point" won't be defined when 
"TBoxProxy" is parsed.



Another strange point is, that the declaration of gt_box doesn't use
the formal specialization paramater `_t_point` at all (in the posted
code), so the same the other way around should also work:



It IS used, because David wants to influence the class the generic class 
gt_box inherits from when specializing the class.


E.g.:

type
  TIntPoint = class
x, y: Integer;
  end;

  TFloatPoint = class
x, y: Single;
  end;

  generic gt_box<_t_point, _num> = class(_t_point)
width, height: _num;
  end;

  TFloatBox = specialize gt_box;
  TIntBox = specialize gt_box;


type
   generic gt_box<_num>  = class<_t_point>
 f_width, f_height : _num;
   end;



This won't compile because of the "<...>" around "_t_point". Also it's 
not what Daniel intends.



A 3rd note is that your code can't compile as _t_point is not declared
when gt_box is declared, but the declaration wants to inherit from
_t_point, so IMO also for this the code is rightfully rejected the
compiler.


The question is whether this should be rejected if "_t_point" is a 
template parameter... on the other hand this would violate compile time 
checks of the generic class...


I'm still thinking how David's idea could be achieved in another way 
which is supported by the compiler...


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[Sven Barth]

On 19.12.2010 02:51, David Emerson wrote:

Sven Barth wrote:

I've now looked at your example code in more detail (I was working the
last time I wrote you). Where did you define "_t_point"? I only found a
"t_point" in your second mail.


_t_point is part of the template list.



Eh... yes, I've missed that one... so much about "looked at in more 
detail" ^^


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[Honza]

2010/12/19 David Emerson :
> type
>  generic gt_box<_t_point,_num> = class (_t_point)   // FAILS :-(
>   f_width, f_height : _num;
>   end;

I think it should fail according to the docs, see:

http://www.freepascal.org/docs-html/ref/refse42.html

"There is a single placeholder _T. It will be substituted by a type
identifier when the generic class is specialized. The identifier _T
*may not be used for anything else than a placehoder*. "

The bold part is IMO violated by the declaration. Anyway, it could be
perhaps (not tested) written as:

type
  TBoxProxy = class(_t_point);
  generic gt_box<_t_point, _num> = class(TBoxProxy)
f_width, f_height : _num;
  end;

Another strange point is, that the declaration of gt_box doesn't use
the formal specialization paramater `_t_point` at all (in the posted
code), so the same the other way around should also work:

type
  generic gt_box<_num> = class<_t_point>
f_width, f_height : _num;
  end;

A 3rd note is that your code can't compile as _t_point is not declared
when gt_box is declared, but the declaration wants to inherit from
_t_point, so IMO also for this the code is rightfully rejected the
compiler.

HTH
-- 
bflm
freepascal-bits.blogspot.com
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[David Emerson]

Sven Barth wrote:
> I've now looked at your example code in more detail (I was working the 
> last time I wrote you). Where did you define "_t_point"? I only found a 
> "t_point" in your second mail.

_t_point is part of the template list.

I guess it's a limitation. Conceptually it doesn't seem that different to be 
specifying a class to inherit from in the template list, but the compiler isn't 
handling it yet.

> Would you please post (or at least attach) your complete test unit? In 
> the meantime I'll try to test it with the code pieces you wrote.

unit genericstest;

{$mode objfpc}

interface

uses
  classes,
  sysutils;

type
  generic gt_point <_num> = class
f_left, f_top : _num;
procedure set_lt (l, t : _num); virtual;
end;

type
  generic gt_box<_t_point,_num> = class (_t_point)   // FAILS :-(
f_width, f_height : _num;
end;

  t_real_point = specialize gt_point;

  t_special_real_point = class (t_real_point)
procedure set_lt (l, t : single); override;
end;

implementation

procedure gt_point.set_lt (l, t : _num);
  begin
f_left := l;
f_top := t;
  end;

procedure t_special_real_point.set_lt (l, t : single);
  begin
inherited;
  end;

end.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[Sven Barth]

On 18.12.2010 22:22, David Emerson wrote:

Would you please state your FPC version the next time? (If you have
stated I, but I haven't seen it: I'm sorry) Some problems might be fixed
in the development version while they aren't in the latest release.


I tried with both 2.4.2 and 2.5.1 (fetched via svn and compiled. Took me quite
some time to figure out how to get it to run properly without installing it as
root)

The main error was the same in both:

genericstest.pas(22,50) Error: Identifier not found "_t_point"

line 22, in "type" context:
   generic gt_box<_t_point,_num>  = class (_t_point)   // FAILS :-(


I've now looked at your example code in more detail (I was working the 
last time I wrote you). Where did you define "_t_point"? I only found a 
"t_point" in your second mail.


Would you please post (or at least attach) your complete test unit? In 
the meantime I'll try to test it with the code pieces you wrote.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] generics class hierarchy

[David Emerson]

> Would you please state your FPC version the next time? (If you have 
> stated I, but I haven't seen it: I'm sorry) Some problems might be fixed 
> in the development version while they aren't in the latest release.

I tried with both 2.4.2 and 2.5.1 (fetched via svn and compiled. Took me quite 
some time to figure out how to get it to run properly without installing it as 
root)

The main error was the same in both:

genericstest.pas(22,50) Error: Identifier not found "_t_point"

line 22, in "type" context:
  generic gt_box<_t_point,_num> = class (_t_point)   // FAILS :-(

Cheers,
David

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal