Difference between FPC Generics and Delphi Generics?

[chronozphere]

Hi,

I would like to use generics, yet keep my code compatible with both Delphi and FPC?

Would that be possible? If so, how to d it?

Thanks

[Murmandamus]

I don't think the implementations differ significantly. At least, I am unable to find any documentation of discrepancies. Generics are pretty straightforward to implement in Object Pascal.

If anything, I would say that the FPC generics are, at worst, a subset of Delphi generics, so anything you do with the FPC ones should port to Delphi without further modification.

[chronozphere]

I think you're wrong. I've been looking into it a bit more and I noticed that FPC uses "generic" and "specialize" keywords, while delphi does not. It makes me think that these two flavours are syntactically quite different.

Has anyone worked with both of them?

[JSoftware]

FPC generics are much stricter than Delphi's implementation. I wouldn't bother with making them compatible. To make them compatible you would need to specialize every generic class

type
{$ifdef FPC}
 generic TGenericType<T> = class
{$else}
 TGenericType<T> = class
{$endif}
  function Test(AArg: T): T;
 end;
 
 TSomeGeneric = {$ifdef FPC}specialize {$endif}TGenericType<longint>;

implementation

function TGenericType.Test(AArg: T): T;
begin
   result := T*2;
end;

[Murmandamus]

Ahh, yeah, looks like the syntax is slightly different because of the reserved words. However, the actual functionality does appear to be a subset.

I haven't used Delphi generics (since I don't have a later copy of Delphi with them), but from what I have discovered in terms of differences so far:

1) Generics in FPC are defined using the "generic" keyword preceding the name of the generic in the declaration, and are "specialized" using the "specialize" keyword. In Delphi, the keywords are not used, but the rest of the syntax appears to be the same (analyzed using several comparative examples in both). This appears to be a decision made by the FPC developers due to a potential conflict with other syntactical elements which use the angle bracket syntax "<>".
2) Generics in Delphi may be specialized in VAR and TYPE declarations. In FPC, they may only be specialized in TYPE declarations. (caveat: it appears you can specialize in a VAR declaration, but there's no way to instantiate the resulting variable, because the constructor expression doesn't understand the "specialized" keyword, or the use of the angle bracket notation).
3) Generics in FPC may not be specialized in local scope; in Delphi, Generics can be specialized in local scope (ie, in a procedure/function/method's local type declaration).

That's what I have found so far; there could be some more caveats to those items, as well as more items; it's not meant to be an exhaustive list, just something to get you started, since the documentation is damn sparse on the subject.

[chronozphere]

Wow.. thanks. Both of you.

I wouldn't bother with making them compatible.

Hmmm.. yes, I was thinking about that. It would be great to have delphi-style generics in FPC (even if it were only in DELPHI mode). It would definitely be a cool feature. But I now understand that it would make no sense to change the FPC implementation to match delphi's. Besides, FPC was WAY earlier with generics support.

Nice trick to use conditional defines. I will probably use that. I'll probably do it this way:

type
{$ifdef FPC}generic{$endif} TGenericType<T> = class
  function Test(AArg: T): T;
 end;
 
 TSomeGeneric = {$ifdef FPC}specialize{$endif} TGenericType<longint>;

implementation

function TGenericType.Test(AArg: T): T;
begin
   result := T*2;
end;

Just saves a couple of lines.

Thanks Murmandamus, for the whole list of differences. Delphi's generics seem a bit more powerfull to me, but I'm not sure how often I will use the extra functionality you mentioned. I think FPC's implementation will do just fine.

[JSoftware]

Generics are overrated anyway

You might save a slight bit of time, but I think it'll only end in tears

[Murmandamus]

Well, they solve some rather sticky problems at the design paradigm level. For example, ages ago, back before classes, I had a number of different internal linked list methods that I created with Objects (think TP 5.5-5.0). If I wanted singly-linked, doubly-linked, circularly-linked, etc options, I had a different object for each combination of options (well, some of them were actually options in the list). When we got classes, it made it easier to manipulate them syntactically, but I still had a number of classes that I had to support so that I could maintain distinctive functionality. Generics solves the last of the problems I had, so I can actually use just one generic TLinkedList class now, but the fact that it is little more than a glorified high-level macro-like extension still doesn't feel like the optimal solution. I think there is still yet more enhancement and integration to be had in the concept, and it will finally be the sweetest syntactic sugar to solve those sticky kinds of problems.

It is definitely nice for some things, but you're right; it's not useful or appropriate to use for many things, even though programmers sometimes go overboard trying to do so.

[VilleK]

In Delphi 2009 and above the new Generics.Collections unit is highly useful.

You can declare containers like this:

X : TObjectList<TMyClass>;

It will hold and own the items.

Then iterate like this:

Item : TMyClass;
...
for Item in X do
...

I like this style of generic containers as it saves time typing and removes the need of casting. There is also a hashtable called TDictionary<K,V>.
But I agree that more advanced use of generics can indeed lead to trouble

[chronozphere]

I will probably only use them for list-like datastructures. It's really handy if you don't have to copy the same code for integers, floats, 2d, 3d and 4d vectors.

Btw, is it possible to use Type Parameter bounds, like java has? It means that you can enforce that your type-parameter T must be a derivative of a specific class, like this:

public class SomeGenericClass <T extends OtherClass> {
    //....
}