Hi,
Am Dienstag, den 08.11.2005, 18:10 -0200 schrieb Felipe Monteiro de
Carvalho:
Hello,
I am trying to understand what exactly generics are. I read the wiki
page, but there are lot's of code examples and very few explanations.
Can someone explain it to me in a (relatively) simple way?
What problem is it trying to solve?
It makes types parametrizable.
For example, if you write a list class, traditional delphi has TList.
However, this TList can only contain TObject, no double/integer/... .
Moreover, you can put objects of *differing* (i.e. unrelated) classes
in the same list, which is most of the time a bad bad idea.
Excuse me for resorting to an example again, but it's just easiest to
see:
1) without generics
type
TAppleList = TList;
TApple = class
end;
TOrange = class
end;
var
apples: TAppleList;
apple: TApple;
begin
apples.Add(TApple.Create); // works
apples.Add(TOrange.Create); // works, and is stupid
apple := apples[0]; // compile error
apple := apples[1]; // compile error
apple := apples[0] as TApple; // manual cast, works
apple := apples[1] as TApple; // compiles, breaks at runtime
end;
Generic types, on the other hand, define just the TList, but do not fix
the contained type in it, but leave it as a parameter to specify later.
2) with generics
type
TListItem = generic(T) record
Data: T;
Next: TListItem(T);
end;
PListItem = ^generic(T) TListItem(T);
TList = generic(T) class
private
fHead: PListItem(T);
fTail: PListItem(T);
published
procedure Add(Item: T);
end;
procedure TList.Add(Item: T);
var
node: PListItem(T);
begin
New(node);
node^.Data := Item;
node^.Next := nil;
if Assigned(fTail) then begin
fTail^.Next := node;
end else begin
fHead := node;
end;
fTail := node;
end;
type
TApple = class
end;
TOrange = class
end;
TAppleList = TList(TApple);
var
apples: TAppleList;
apple: TApple;
begin
apples.Add(TApple.Create); // works
apples.Add(TOrange.Create); // compile error
apple := apples[0]; // works
apple := apples[1]; // not applicable
apple := apples[0] as TApple; // works, but unneccessary
apple := apples[1] as TApple; // not applicable
end;
And how do generics relate to interfaces?
interfaces in pascal are mostly runtime-bound.
Generics are mostly resolved at compile time.
Otherwise quite similar, with the exception that there is no "mother of
everyone" class, that is, a class which is the base class of all other
types, also of i.e. Integer.
i.e.
Integer = class(TAll, IUnknown);
Double = class(TAll, IUnknown);
Boolean = class(TAll, IUnknown);
TObject = class(TAll, IUnknown);
TFoo = class(TObject);
note that I'm not advertising that there should be one, just noting the
facts.
The fact being, if there were one, interfaces would do the same as
generics, just at runtime.
Without one, interfaces do nearly the same as generics (just don't work
for simple types), but still work only at runtime (at huge "cost").
Doing stuff at runtime slows the program down, and also note that the
more you do at runtime, the more stuff the compiler has to compile in at
each place just in case something x or y happens at runtime, at every
place.
Worse, if the language is not really designed for stuff to be determined
at runtime (i.e. late bound stuff), it sucks. Therefore you have to add
"as TApple". Because the language just doesn't expect that you want it
to automagically upcast back to what it was.
If it were a language designed for stuff to be determined at runtime too
(late bound), from the line
apple := apples[0];
it would automagically generate (invisible for the programmer, but in
the executable):
var
temp: TObject;
temp := apples[0];
if apple is TApple then
apple := temp as TApple
else
raise ETypeError.Create...;
that is, it would add code for "runtime type inference".
(Note that the "is TApple" and "as TApple" are the destination type of
the variable "apple", i.e. the compiler still wouldn't know what type is
_in_ the list, it just knows you _want_ to have an TApple.
If you instead specified orange: TOrange; and accessed: orange :=
apples[0];, fine, it will cast to TOrange, "you asked for it, you get
it")
Which would be a little better than now, but slower.
(as a side note, note the only reason why anybody bothers with type safe
compiled languages is strong type checking, that is total _compile time_
strong type checking, also known as "if it compiles, it works (mostly)".
If it weren't for that advantage (ok, and the speed advantage when done
right), nobody would use strongly typed languages)
Generics, therefore, move the complexity into the type checker of the
compiler instead, the benefit being generation of faster code,
compile-time (automatically) verifyable code, but at the cost of a
larger executable size.
thanks,
Felipe Monteiro de Carvalho
I hope I didn't commit major blunders in the explaination, but it should
be about right :)
cheers,
Danny
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
