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-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

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

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

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

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

[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

[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

[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

[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

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

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

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

[silvioprog]

On Sat, Nov 1, 2014 at 9:04 AM, Sven Barth pascaldra...@googlemail.com
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;

TGenT: class, constructor = class
end;

 constructor TTest.Create;
 begin
 end;

 var  Gen: TGenTTest;
 begin
Gen := TGenTTest.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
   TGenericT = class
 procedure Test;
   end;

 procedure TGenericT.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

[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 silviop...@gmail.com
έγραψε:

 On Sat, Nov 1, 2014 at 9:04 AM, Sven Barth pascaldra...@googlemail.com
 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;

TGenT: class, constructor = class
end;

 constructor TTest.Create;
 begin
 end;

 var  Gen: TGenTTest;
 begin
Gen := TGenTTest.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
   TGenericT = class
 procedure Test;
   end;

 procedure TGenericT.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

[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;

   TGenT: class, constructor = class
   end;

constructor TTest.Create;
begin
end;

var  Gen: TGenTTest;
begin
   Gen := TGenTTest.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
  TGenericT = class
procedure Test;
  end;

procedure TGenericT.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

Re: [fpc-pascal] Generics Syntax

[silvioprog]

2014-02-27 19:36 GMT-03:00 Fabrício Srdic fabricio.sr...@gmail.com:

 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

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

[Fabrício Srdic]

Thanks for clarifying!


2014-02-27 21:34 GMT-03:00 leledumbo leledumbo_c...@yahoo.co.id:

 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 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 (TAT, TAT1, T2) 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 pascaldra...@googlemail.com:

 Am 13.02.2014 01:28, schrieb silvioprog:

 Hello,

 Can I use it:

 TBrookActionTBrookEntity = class(TBrookObject)
 ...

 instead of?:

 generic TBrookActionTBrookEntity = class(TBrookObject)
 ...

 And, can I use it:

 TPersonAction = class(TBrookActionTPerson)
 ...

 instead of?:

 TPersonAction = class(specialize TBrookActionTPerson)
 ...

 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:

TBrookActionTBrookEntity = class(TBrookObject)
...

instead of?:

generic TBrookActionTBrookEntity = class(TBrookObject)
...

And, can I use it:

TPersonAction = class(TBrookActionTPerson)
...

instead of?:

TPersonAction = class(specialize TBrookActionTPerson)
...

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

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 mar...@lmspathologie.nl
 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 string, TMyObject;
 
 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

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

[Sven Barth]

Am 07.04.2013 23:09 schrieb Dimitri Smits smi...@telenet.be:

 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 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 FirmOS Business Solutions GmbH 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: TGUndefinedKey;
  root:  PFOS_RB_NodeG;
  

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 jc...@acm.org
Reply-to: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
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 vs TCollection

[Graeme Geldenhuys]

On 9 November 2011 22:08, Michael Van Canneyt michael@ 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

[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 michael.vancann...@wisa.be
À: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
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

[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

[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 michael.vancann...@wisa.be
À: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
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

[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

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

[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

[michael . vancanneyt]

On Tue, 8 Nov 2011, Graeme Geldenhuys wrote:


On 8 November 2011 12:13,  michael.vancanneyt@... 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 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
   TTestGenT  = 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 TTestGenT.Create();
begin
end;

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


type
   TTestInt = TTestGenInteger;
   TTestString = TTestGenString;

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

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 ...; TListT = class ...; TListT, TT = class ...;

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

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

[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
  IDelegateT = interface
procedure Add(const Handler: T);
procedure Remove(const Handler: T);
  end;

And then specialize using the following syntax:

type
  INotifyDelegate = IDelegateTNotifyEvent;

Also, generic constraints are needed:

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

On Fri, Apr 29, 2011 at 3:28 PM, leledumbo leledumbo_c...@yahoo.co.idwrote:

 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

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 ...; TListT = class ...; TListT, TT = class ...;

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

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 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

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

[Tim Veldhuizen]

Hi,

2011/3/30 Žilvinas Ledas zilvinas.le...@dict.lt
 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?

[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 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

[Sven Barth]

On 19.12.2010 08:34, Honza wrote:

2010/12/19 David Emersondle...@angelbase.com:

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_boxTFloatPoint, Single;
  TIntBox = specialize gt_boxTIntPoint, Integer;


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

[David Emerson]

On Sat 18 Dec 2010, Honza wrote:
 2010/12/19 David Emerson dle...@angelbase.com:
  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

[Honza]

2010/12/19 Sven Barth pascaldra...@googlemail.com:
 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_boxTFloatPoint, Single;
  TIntBox = specialize gt_boxTIntPoint, Integer;

 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

[Honza]

2010/12/19 David Emerson dle...@angelbase.com:

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

[Sven Barth]

On 19.12.2010 13:03, Honza wrote:

2010/12/19 Sven Barthpascaldra...@googlemail.com:

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 Sven Barth pascaldra...@googlemail.com:
 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

[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

[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

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]

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_pointsingle;

  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

[Honza]

2010/12/19 David Emerson dle...@angelbase.com:
 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

[Sven Barth]

Am 17.12.2010 03:30, schrieb David Emerson:

err... my mistake. the error message was referring to a different problem, which
I was blind to in my hurry. Sorry for all the messages. I'll shut up now. :)



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.


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]

I'll give a little more detail...

Right now I have these non-generic types:

t_point = class
  f_left, f_top : longint;  // so named for descendents
  // several fields and methods to manage it as I need
  end;

t_box = class (t_point)
  f_width, f_height : longint;
  // more fields and methods to manage it as I need
  end;


They've been great.
Now I have need for a point and box that use real coordinates. The structure 
would be identical -- simply replacing longint with single -- which is why 
I thought generics would be perfect.

However, t_box inherits from t_point, and this appears to be a sticking point.

My code looks like this:


generic gt_point_num = class
  f_left, f_top : _num;
  // other fields, methods
  end;

generic gt_box_t_point,_num = class (_t_point)
  f_width, f_height : _num;
  // other fields, methods
  end;

t_real_point = specialize gt_pointsingle;

t_real_box = specialize gt_boxt_real_point,single;


Thanks all!
~David.

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

Re: [fpc-pascal] generics class hierarchy

[David Emerson]

Well, I'm guessing generics aren't really ready to be fully used... I'm getting 
an error There is no method in an ancestor class to be overridden where the 
ancestor class was a specialized generic. Doesn't seem very promising for 
actual use.

So I'm abandoning generics for now. Hopefully they'll become more usable in the 
future!

Keep up the good work, guys

Cheers,
David


...here's what I couldn't do:

generic gt_point_num = class
  f_left, f_top : _num;
  procedure set_lt (l, t : _num); virtual;
  end;

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

generic gt_box_t_point,_num = class (_t_point)   // FAILS :-(
  f_width, f_height : _num;
  end;

t_real_point = specialize gt_pointsingle;

t_real_box = specialize gt_boxt_real_point,single;

t_special_real_box = class (t_real_box)
  procedure set_lt (l, t : single); override;  // FAILS :-(
  end;


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

Re: [fpc-pascal] generics class hierarchy

[David Emerson]

err... my mistake. the error message was referring to a different problem, 
which 
I was blind to in my hurry. Sorry for all the messages. I'll shut up now. :)

On Thu 16 Dec 2010, David Emerson wrote:
 Well, I'm guessing generics aren't really ready to be fully used... I'm 
getting 
 an error There is no method in an ancestor class to be overridden where the 
 ancestor class was a specialized generic. Doesn't seem very promising for 
 actual use.
 
 So I'm abandoning generics for now. Hopefully they'll become more usable in 
the 
 future!
 
 Keep up the good work, guys
 
 Cheers,
 David
 
 
 ...here's what I couldn't do:
 
 generic gt_point_num = class
   f_left, f_top : _num;
   procedure set_lt (l, t : _num); virtual;
   end;
 
 procedure gt_point.set_lt (l, t : _num);
   begin
 f_left := l;
 f_top := t;
   end;
 
 generic gt_box_t_point,_num = class (_t_point)   // FAILS :-(
   f_width, f_height : _num;
   end;
 
 t_real_point = specialize gt_pointsingle;
 
 t_real_box = specialize gt_boxt_real_point,single;
 
 t_special_real_box = class (t_real_box)
   procedure set_lt (l, t : single); override;  // FAILS :-(
   end;
 
 
 ___
 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 problem/question

[Aleksa Todorovic]

On Tue, Jan 19, 2010 at 18:35, Aleksa Todorovic alexi...@gmail.com wrote:
 On Mon, Jan 18, 2010 at 04:07, Aleksa Todorovic alexi...@gmail.com wrote:

 One (not very nice) way to have generic list of records is using
 macros. I've extracted definition of TFPGList, made it ordinary type,
 and did some search/replace, so I get:

 [SNIP]


Just to report how I managed to (ab)use FPC and Lazarus to have both
generics of records and full code-completition (note I turned C-style
macros on for the whole project):

in interface:

  TMessageParameter = record
...
  end;

  TMessageParameters = TList; // this makes Lazarus code completition
actually work; maybe better to use TFPSList

operator = (const A, B: TMessageParameter): Boolean;

{$DEFINE _TFPGList_Type_ := TMessageParametersFPGList}
{$DEFINE _TFPGList_ItemType_ := TMessageParameter}
{$INCLUDE fpglist_h.inc} // copied and adapted interface from FGL
{$DEFINE TMessageParameters := TMessageParametersFPGList}
// last line is used to make it all actually work


in implementation:

operator = (const A, B: TMessageParameter): Boolean;
begin
  Result := ...;
end;

{$DEFINE _TFPGList_Type_ := TMessageParametersFPGList}
{$DEFINE _TFPGList_ItemType_ := TMessageParameter}
{$INCLUDE fpglist.inc} // copied and adapted implementation from FGL
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics problem/question

[Aleksa Todorovic]

On Mon, Jan 18, 2010 at 04:07, Aleksa Todorovic alexi...@gmail.com wrote:

 The proper solution for this problem is not simple. Somehow, you will
 have to make operator = (const A, B: TPar) visible inside FGL unit
 (because of the way generics are currently implemented), or make
 compiler think that TPGList is implemented in the place where
 specialization occurs (so compiler first searches specialization
 space, and after that generic-declaration space).


One (not very nice) way to have generic list of records is using
macros. I've extracted definition of TFPGList, made it ordinary type,
and did some search/replace, so I get:

type
  _TFPGList_Type_ = class(TFPSList)
  type public
TCompareFunc = function(const Item1, Item2: _TFPGList_ItemType_): Integer;
TTypeList = array[0..MaxGListSize] of _TFPGList_ItemType_;
PTypeList = ^TTypeList;
PT = ^_TFPGList_ItemType_;
  [original code from FGL unit goes here]
  end;

constructor _TFPGList_Type_.Create;
begin
[...]
end;

[...]

Now, you insert code like this:

type
  TPar = record
I: Integer;
  end;

operator = (const A, B: TPar): Boolean;
begin
  Result := (A.I = B.I);
end;

{$MACRO ON}
{$DEFINE _TFPGList_Type_ := TParList}
{$DEFINE _TFPGList_ItemType_ := TPar}
{$INCLUDE fpglist.inc}
{$MACRO OFF}

And you get list of TPar records!

Now, The Question is: should specialize construct also search
symbols defined in the place where specialization occurs, not just
those defined in the place where generic type is defined?

On the other hand, the only problem so far (regarding this matter) is
operator = on records. Maybe there should be special rule for this
situation?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics problem/question

[Aleksa Todorovic]

On Fri, Jan 15, 2010 at 09:00, leledumbo leledumbo_c...@yahoo.co.id wrote:

 Ah... I can see it now:

 711  function TFPGList.IndexOf(const Item: T): Integer;
 712  begin
 713    Result := 0;
 714    {$info TODO: fix inlining to work! InternalItems[Result]^}
 715    while (Result  FCount) and (PT(FList)[Result]  Item) do
 716      Inc(Result);
 717    if Result = FCount then
 718      Result := -1;
 719  end;

 This is where the = operator is required ( is derived from = ).

 I continue the discussion in mantis, so that this can be solved (hopefully).

I've attached patch to mantis bug which makes compiler print error
about missing operator TPar = TPar. This could, at least, give
user some hint about what is wrong.

The proper solution for this problem is not simple. Somehow, you will
have to make operator = (const A, B: TPar) visible inside FGL unit
(because of the way generics are currently implemented), or make
compiler think that TPGList is implemented in the place where
specialization occurs (so compiler first searches specialization
space, and after that generic-declaration space).
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics problem/question

[leledumbo]

Ah... I can see it now:

711  function TFPGList.IndexOf(const Item: T): Integer;
712  begin
713Result := 0;
714{$info TODO: fix inlining to work! InternalItems[Result]^}
715while (Result  FCount) and (PT(FList)[Result]  Item) do
716  Inc(Result);
717if Result = FCount then
718  Result := -1;
719  end;

This is where the = operator is required ( is derived from = ).

I continue the discussion in mantis, so that this can be solved (hopefully).
-- 
View this message in context: 
http://old.nabble.com/Generics-problem-question-tp27036004p27173345.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 problem/question

[Honza]

Hi all.

At Mantis Florian already explained, why it is not possible to provide
more information in the error message. Still he meanwhile managed to
make it better. I got some time to return to this and now I'm here:

17:11 myn...@tux64:~/fpc/bugreports/20100105$ cat project1.pas
program project1;

{$mode objfpc}{$H+}

uses
fgl;

type
  TPar = record
I: Integer;
  end;

operator = (A, B: TPar): Boolean;
begin
Result := A.I = B.I;
end;

type
  TSpec = specialize TFPGListTPar;

begin
end.

17:22 myn...@tux64:~/fpc/bugreports/20100105$ fpc project1.pas
Free Pascal Compiler version 2.5.1 [2010/01/14] for x86_64
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for x86-64
Compiling project1.pas
Error: Operator is not overloaded: record type = record type
project1.pas(24) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /home/myname/lib/fpc/2.5.1/ppcx64 returned an error exitcode
(normal if you did not specify a source file to be compiled)
17:22 myn...@tux64:~/fpc/bugreports/20100105$ svn info ~/svn/fpc/trunk
Path: /home/myname/svn/fpc/trunk
URL: http://svn2.freepascal.org/svn/fpc/trunk
Repository Root: http://svn2.freepascal.org/svn/fpc
Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2
Revision: 14633
Node Kind: directory
Schedule: normal
Last Changed Author: paul
Last Changed Rev: 14633
Last Changed Date: 2010-01-14 09:41:27 +0100 (Čt, 14 led 2010)

17:23 myn...@tux64:~/fpc/bugreports/20100105$

I'm now able to track the source of the error message to line 715:50
of rtl/objpas/fgl.pp:

711  function TFPGList.IndexOf(const Item: T): Integer;
712  begin
713Result := 0;
714{$info TODO: fix inlining to work! InternalItems[Result]^}
715while (Result  FCount) and (PT(FList)[Result]  Item) do
716  Inc(Result);
717if Result = FCount then
718  Result := -1;
719  end;

Still I'm stuck and don't know how to use items like TPar in the
specialization of TFPGList - or if it is a compiler bug.

Thanks in advance for anyone's help/explanation/hint.

-bflm

Topic/previous messages context:
http://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg18933.html

Mantis issue:
http://bugs.freepascal.org/view.php?id=15480
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics problem/question

[Honza]

Submitted: http://bugs.freepascal.org/view.php?id=15480
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics problem/question

[leledumbo]

 I tried that, but it didn't work

Are you sure? Can you compile the attached program (See TicTacToe unit)? I
only define = operator and it works.
http://old.nabble.com/file/p27056857/TicTacToeAI.zip TicTacToeAI.zip 
-- 
View this message in context: 
http://old.nabble.com/Generics-problem-question-tp27036004p27056857.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 problem/question

[leledumbo]

Sorry, I guess I was wrong. The specialization in my program uses a class
instead of a record, the = operator is defined for a record but isn't used
at all. I'm not sure where the problem is, only records and static arrays
causes it.

One solution is to declare a pointer type to your record and specialize
TFPGList with it.

-- 
View this message in context: 
http://old.nabble.com/Generics-problem-question-tp27036004p27070857.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 problem/question

[leledumbo]

The error message needs to be extended for generics type.

Inside TFPGList in implementation section, there are some comparisons done
with relational operators (I forgot what they are, just open fgl.pp). You
need to overload those operators for your record type. Surely, the compiler
wouldn't know how to compare 2 TPar without the overloading.
-- 
View this message in context: 
http://old.nabble.com/Generics-problem-question-tp27036004p27056130.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 problem/question

[Marco van de Voort]

In our previous episode, leledumbo said:
 
 Inside TFPGList in implementation section, there are some comparisons done
 with relational operators (I forgot what they are, just open fgl.pp). You
 need to overload those operators for your record type. Surely, the compiler
 wouldn't know how to compare 2 TPar without the overloading.

I tried that, but it didn't work (defined  =  )
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics problem/question

[Marco van de Voort]

In our previous episode, leledumbo said:
 Inside TFPGList in implementation section, there are some comparisons done
 with relational operators (I forgot what they are, just open fgl.pp). You
 need to overload those operators for your record type. Surely, the compiler
 wouldn't know how to compare 2 TPar without the overloading.

One of the problems is the limited information in the errormsg (what
operator is missing in what line)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generics Red Black Tree for fpc

[Mattias Gaertner]

On Fri, 3 Apr 2009 13:08:42 +0200
Helmut Hartl helmut.ha...@firmos.at wrote:

 Hi all,
 
 due to interest i post here our generic version of a red black tree
 implementation. A R/B tree is a quite fast directory datastructure
 which allows o(log n) access times.
 
 Warning: The code compiles only under 2.2.4RC1+, below that the
 compilation fails(crash).
 
 Further info on
 http://fpcfun.firmos.at/bin/view/Freepascal/FirmOSOpenSource
 
 A short description with usage guidelines and a testprogram
 demonstrating adding and searching 10 Million key / value pairs is
 provided there too. 
 
 The code was tested under FreeBSD (dev platform), linux and windows
 and has no dependancys.
 
 have fun,

I surely have.

How much work do you think is it to extend it to accept duplicate keys?


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

AW: Re: [fpc-pascal] Generics Red Black Tree for fpc

[Helmut Hartl]

Von: Mattias Gaertner nc-gaert...@netcologne.de
Gesendet: Fr 03.04.2009 16:51
An: fpc-pascal@lists.freepascal.org; 
Betreff: Re: [fpc-pascal] Generics Red Black Tree for fpc

 How much work do you think is it to extend it to accept duplicate keys?
 Mattias

How probable are duplicate keys in your usecase? / what is the use case ?
It would be easy to add them as list per key node natively, but that would be 
possible with
the current version too if you use a listtype as the storage type ...

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

Re: [fpc-pascal] Generics Red Black Tree for fpc

[Mattias Gaertner]

On Fri, 3 Apr 2009 17:16:50 +0200
Helmut Hartl helmut.ha...@firmos.at wrote:

 Von: Mattias Gaertner nc-gaert...@netcologne.de
 Gesendet: Fr 03.04.2009 16:51
 An: fpc-pascal@lists.freepascal.org; 
 Betreff: Re: [fpc-pascal] Generics Red Black Tree for fpc
 
  How much work do you think is it to extend it to accept duplicate
  keys? Mattias
 
 How probable are duplicate keys in your usecase? / what is the use
 case ? It would be easy to add them as list per key node natively,
 but that would be possible with the current version too if you use a
 listtype as the storage type ...

Of course duplicates are very unlikely, but chance is not 0. Approx 80%
of my trees must therefore support duplicates.
Using lists in the nodes would cost speed and memory (duplicates are
seldom), so I would prefer a more direct support.

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

AW: Re: [fpc-pascal] Generics Red Black Tree for fpc

[Helmut Hartl]

Von: Mattias Gaertner nc-gaert...@netcologne.de
Gesendet: Fr 03.04.2009 18:07
An: fpc-pascal@lists.freepascal.org; 
Betreff: Re: [fpc-pascal] Generics Red Black Tree for fpc

 On Fri, 3 Apr 2009 17:16:50 +0200
 Helmut Hartl helmut.ha...@firmos.at wrote:
 
  Von: Mattias Gaertner nc-gaert...@netcologne.de
  Gesendet: Fr 03.04.2009 16:51
  An: fpc-pascal@lists.freepascal.org; 
  Betreff: Re: [fpc-pascal] Generics Red Black Tree for fpc
  
   How much work do you think is it to extend it to accept duplicate
   keys? Mattias
  
  How probable are duplicate keys in your usecase? / what is the use
  case ? It would be easy to add them as list per key node natively,
  but that would be possible with the current version too if you use a
  listtype as the storage type ...
 
 Of course duplicates are very unlikely, but chance is not 0. Approx 80%
 of my trees must therefore support duplicates.
 Using lists in the nodes would cost speed and memory (duplicates are
 seldom), so I would prefer a more direct support.
 
 Mattias

I can think of two possible ways of allowing duplicates:

a) the internal node structure gets another pointer for the next duplicated 
storage value. 
(single linked list). The tree structure does not change. If duplicates are not 
very
probable the linked list is sufficiently small to not give a huge performance 
penalty.
The order of access would then be log(n)+k, where k ist the amount of 
duplicates.
We have one pointer more per node. The time to scan the whole tree linear would 
be n*log(n).
The tree semantics for a random access with duplicates would not be very clean: 
1) first scan for a key
2) check if duplicates exist
3) scan the duplicate list
Implementation would be easy, memory cost just one additional pointer, maybe 
the duplicate count in the node.

b)
We add 2 pointers in double linked list fashion to the tree node structure and 
link each node against its pred and next node. If we insert a duplicate we do 
it only in the list, not in the tree structure.
We could then lineary scan the tree faster in the order of n, by traversing the 
list and rembering the last element - and in log(n) for a random access. 
Semantics for the access would be cleaner.
1) Search the key
2) call next until the key changes


Background Info:
This tree + semantic is designed for heavy multiprocessor/multithreading loads, 
therefor the
interface must be kept as simple as possible. If you have multiple threads 
reading and writing concurrently on the tree, one thread(A) can search the tree 
by only rembering the active key, 
while two other thread (C,D) may delete or insert nodes. If thread A gets 
interupted in the scan then he can continoue with his last key value and finds 
the next node, making progress.
If thread A would remember a pointer to the node, he could search the tree in 
order n (not the described n*log(n) but has to deal with deleted nodes, 
ABA-Problems and much headache - or the tree (as directory) must be locked as a 
whole while processing a linear scan. (which is practically two inefficient and 
slow).

Which means as conclusion that the speed benefit of solution b) will vanish.
A solution to the whole cause could be a STM (software transactional memory) 
which i currently 
work on - but thats far away from production quality ...

So i would propose solution A) with the following semantics for a random acess 
- if the
tree would be intended for multithreaded usage - for single threaded usage i 
would propose solution B).

A)
1) Search the key with a function:
function Find(const key:_TKey;out node:_TStore;const 
DuplicateIterator:TIteratorFunc):Boolean;
where you pass an iteratorfunction which gets called for every extra duplicate.

The multithreaded access could then be:
1) Lock the directory (r/b tree) 
2) Find the key and fetch the objects and duplicates, lock them
3) unlock the tree
4) process the objects/data

i hope i was somewhat clear :-) 

If it is of value i would implement a solution.

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

Re: [fpc-pascal] Generics

[ik]

After you define the generic you must first create a type for it:

type
TMyMcollection = specialize TMCollectionString;

And use the TMyMcollection.
It seems like hard work, but it is much better then the way it look on
a bad C++ and Java code :)

Ido

On Mon, Mar 31, 2008 at 4:00 PM, Damien Gerard [EMAIL PROTECTED] wrote:

  I would like to make a generic class, like this :

  {$mode objfpc}

  generic TMCollection_T = class(TObject)
  private
  FDefaultItem: _T;  // line 35
  public
  constructor Create;
  destructor Destroy;override;
  [...]
  end;


  But I have got the following :
  commons.pas(35,21) Error: Identifier not found _T
  commons.pas(35,21) Error: Error in type definition
  commons.pas(39,34) Error: Identifier not found _T
  commons.pas(44,84) Error: Identifier not found _T

  According to the documentation, I should use `var private`, but I have
  got :

  Compiling ./commons.pas
  commons.pas(33,3) Error: VAR and TYPE are allowed only in generics
  commons.pas(35,21) Error: Identifier not found _T

  Could someone tell me where I am wrong ?
  Thanks !



  --
  Damien Gerard
  [EMAIL PROTECTED]

  Intelligence is 10 million rules.
 -- Douglas Lenat





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




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

Re: [fpc-pascal] Generics

[Damien Gerard]

Le Mar 31, 2008 à 3:20 PM, ik a écrit :

After you define the generic you must first create a type for it:

type
TMyMcollection = specialize TMCollectionString;



Sorry but it did not change anything.
Additionally, I would prefer to define the specialization in another  
unit.



And use the TMyMcollection.
It seems like hard work, but it is much better then the way it look on
a bad C++ and Java code :)



:)



Ido

On Mon, Mar 31, 2008 at 4:00 PM, Damien Gerard  
[EMAIL PROTECTED] wrote:


I would like to make a generic class, like this :

{$mode objfpc}

generic TMCollection_T = class(TObject)
private
FDefaultItem: _T;  // line 35
public
constructor Create;
destructor Destroy;override;
[...]
end;


But I have got the following :
commons.pas(35,21) Error: Identifier not found _T
commons.pas(35,21) Error: Error in type definition
commons.pas(39,34) Error: Identifier not found _T
commons.pas(44,84) Error: Identifier not found _T

According to the documentation, I should use `var private`, but I  
have

got :

Compiling ./commons.pas
commons.pas(33,3) Error: VAR and TYPE are allowed only in generics
commons.pas(35,21) Error: Identifier not found _T

Could someone tell me where I am wrong ?
Thanks !



--
Damien Gerard
[EMAIL PROTECTED]

Intelligence is 10 million rules.
   -- Douglas Lenat





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





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




--
Damien Gerard
[EMAIL PROTECTED]

Intelligence is 10 million rules.
   -- Douglas Lenat





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

Re: [fpc-pascal] Generics

[Damien Gerard]

Le Mar 31, 2008 à 3:00 PM, Damien Gerard a écrit :


I would like to make a generic class, like this :

{$mode objfpc}

generic TMCollection_T = class(TObject)
private
   FDefaultItem: _T;  // line 35
public
   constructor Create;
   destructor Destroy;override;
   [...]
end;


But I have got the following :
commons.pas(35,21) Error: Identifier not found _T
commons.pas(35,21) Error: Error in type definition
commons.pas(39,34) Error: Identifier not found _T
commons.pas(44,84) Error: Identifier not found _T

According to the documentation, I should use `var private`, but I  
have got :


Compiling ./commons.pas
commons.pas(33,3) Error: VAR and TYPE are allowed only in generics
commons.pas(35,21) Error: Identifier not found _T

Could someone tell me where I am wrong ?
Thanks !





I forgot : fpc 2.2.0 and fpc 2.2.1. May be I should upgrade to 2.3.x ?


--
Damien Gerard
[EMAIL PROTECTED]

Intelligence is 10 million rules.
   -- Douglas Lenat





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

Re: [fpc-pascal] Generics

[ik]

Can you create a small proof of concept, and attach it here ?

Ido

On Mon, Mar 31, 2008 at 4:27 PM, Damien Gerard [EMAIL PROTECTED] wrote:

  Le Mar 31, 2008 à 3:00 PM, Damien Gerard a écrit :

 
   I would like to make a generic class, like this :
  
   {$mode objfpc}
  
   generic TMCollection_T = class(TObject)
   private
  FDefaultItem: _T;  // line 35
   public
  constructor Create;
  destructor Destroy;override;
  [...]
   end;
  
  
   But I have got the following :
   commons.pas(35,21) Error: Identifier not found _T
   commons.pas(35,21) Error: Error in type definition
   commons.pas(39,34) Error: Identifier not found _T
   commons.pas(44,84) Error: Identifier not found _T
  
   According to the documentation, I should use `var private`, but I
   have got :
  
   Compiling ./commons.pas
   commons.pas(33,3) Error: VAR and TYPE are allowed only in generics
   commons.pas(35,21) Error: Identifier not found _T
  
   Could someone tell me where I am wrong ?
   Thanks !
  



  I forgot : fpc 2.2.0 and fpc 2.2.1. May be I should upgrade to 2.3.x ?




  --
  Damien Gerard
  [EMAIL PROTECTED]

  Intelligence is 10 million rules.
 -- Douglas Lenat





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




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

Re: [fpc-pascal] Generics

[Damien Gerard]

Le Mar 31, 2008 à 3:59 PM, ik a écrit :

Can you create a small proof of concept, and attach it here ?



Here you are.
The unit is in development so it may remain some errors (I would like  
to convert another units with the use of generics).


BTW, is there a way to specifiy the template parameter must be a  
descendant of another class ?



Ido

On Mon, Mar 31, 2008 at 4:27 PM, Damien Gerard  
[EMAIL PROTECTED] wrote:


Le Mar 31, 2008 à 3:00 PM, Damien Gerard a écrit :



I would like to make a generic class, like this :

{$mode objfpc}

generic TMCollection_T = class(TObject)
private
  FDefaultItem: _T;  // line 35
public
  constructor Create;
  destructor Destroy;override;
  [...]
end;


But I have got the following :
commons.pas(35,21) Error: Identifier not found _T
commons.pas(35,21) Error: Error in type definition
commons.pas(39,34) Error: Identifier not found _T
commons.pas(44,84) Error: Identifier not found _T

According to the documentation, I should use `var private`, but I
have got :

Compiling ./commons.pas
commons.pas(33,3) Error: VAR and TYPE are allowed only in generics
commons.pas(35,21) Error: Identifier not found _T

Could someone tell me where I am wrong ?
Thanks !





I forgot : fpc 2.2.0 and fpc 2.2.1. May be I should upgrade to  
2.3.x ?






foo.pas
Description: Binary data





--
Damien Gerard
[EMAIL PROTECTED]

Intelligence is 10 million rules.
   -- Douglas Lenat





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

Re: [fpc-pascal] Generics

[Marco van de Voort]

 Le Mar 31, 2008 ? 3:00 PM, Damien Gerard a ?crit :
 
 I forgot : fpc 2.2.0 and fpc 2.2.1. May be I should upgrade to 2.3.x ?

Afaik you need 2.3.x. A recent one (of this year).
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal