False premise. Constraints aren’t casts, and you don’t pay a runtime cost. Constraints are checked at compile time.

The cost you do pay for using an interface is due to (1) the virtual methods and (2) the reference counting, not the generic constraint. You can use a base object type as the generic constraint to avoid it. You will have exactly the same performance characteristics when using interfaces without generics.

I will say, though, that the performance problems associated with virtual method dispatch may be fixable in some future, improved version of the compiler. As an example, look at what the V8 JavaScript engine does.

for the record, some sort of template coding was already possible in previous versions of Delphi :
-the "{$INCLUDE }" directive allows you to paste verbatim source code from some other file,
-Delphi allows you to give any name to any existing type.

So you can write :

UNIT MappingIntegerString;

INTERFACE

TYPE
_TEMPLATE_KEY_TYPE_ = Integer;
_TEMPLATE_ITEM_TYPE_ = String;

{$INCLUDE ‘GenericMappingInterface.inc’} //<- file where you write declarations using references to types names _TEMPLATE_KEY_TYPE_ and _TEMPLATE_ITEM_TYPE_

TMappingIntegerString = _TEMPLATE_MAPPING_TYPE_ //<- likewise, you choose in GenericMappingInterface.inc the convention for the name of the resulting class/record/…

IMPLEMENTATION

{$INCLUDE ‘GenericMappingImplementation.inc’} //<- file containing your template ipmplementation, using the same name conventions as above

END.

We are making extensive use of this feature with our Delphi projects.
The gain is pretty straightforward.
The main drawback with this method is that you have to explicitly create a separate Unit file for each instance of your template, since declaring 2 different versions of a template -e.g. MappingIntegerString and MappingIntegerInteger- in the same unit would result in a name conflict with the types.
With this method, you have the same debugging issues as templates in C++ : you potentially have different bugs for different instances of your template, caused for various reasons, and the compiler is obviously not adapted to check types and coherence in partial source files (in this case : the two .inc files used).

We are currently moving to Delphi 2009, and are pretty excited with the Generic type features for win32 (our projects are all for win32 platform).
However, we already saw several drawbacks :
-first, the CodeGear team did a terrific job at including generic types in a compiled language, but there are still too many bugs in the implementation (the first released version prevented to use pointers on generic types, there are still some strange compiling issues with method declaration…) ;
-second, we made some performance test, and going through *runtime* interfaces for generic types just doesn’t make it - we will still have to use our home brewed templates for performance issues in computation intensive parts.

Though I am really looking forward to use the neat genric syntax, I will go with Sergey : why, in a *compiled* language which produces compiled, typefree, static asm code do we have to pay a *runtime* overhead for static type constrains?

Thanks, Craig. I didn’t know that was possible. I can think of a number of ways that would be very useful.

"OK, I see that I’m going to have to write some more posts on this subject in order to cover some of the questions and assertions in comments."

I’d find another post interesting, and it would be great to have more information about some of this. Thanks for this one, though!

Thank you again.

If your list of type constraints starts looking like a class definition, and I would question how "generic" your type really is?

The class parametrization is just the way to define generic behaviour.

So, the expression
(U+T*Z-V*10*(cast to V) (U))/U is still generalized.

But for code generation there must be a guarantee to accomplish compilation process successfully.

For intermediate platforms, for generic IL code there is needs for additional info(constraints) to guarantee safe code.
At compile time that analysis of course may be carried out by compiler on source code.
So instantiation may valid. But at run time instantiation without constraints results in needs for reverse engineering of IL code to deduce constraints violation(an code of course).
But instantiation of .NET generics occurs at run time so no constraints, no safe code.

So for native platforms, there is no needs in any constraints, because all may be infered at compile time. But with one restriction there are no way to instantiate Generic class at run time with rational effort of course.

> In short, it’s a limitation of the compiler, and one >which isn’t likely to go away soon.

The key words here is the limitation of the compiler. I think that the inner representation
of parse tree is only the inner representation.

Suppose the next code

SomeClassA=class(Some)
procedure abc;
end;

Why I can not write?

procedure SomeClassA.abc;
asm
end;

No dependency.
Where and what is the barrier?
What do you think about the relocable asm code representation in dcu?

Or the next one

procedure SomeClassA.abc;
var a,b:T;
begin
…
a:=b;

{relocable code.}
asm
lea eax,[a];
end;
…
b:=a;
..
end;

But!!! I think
Problem is that generics in native Delphi is a satelite of generics in Delphi.NET.
Resriction of using operators on T is just restriction of .NET.

How many generic type constraints must a programmer declare? As many as you need, for the code you have to write. If your list of type constraints starts looking like a class definition, and I would question how "generic" your type really is. Generally, one uses interfaces for such "heavily constrained" type arguments, but in Delphi we have to work around that for types which cannot use interfaces, i.e., primitive types.

First of all about bug,

procedure Some"T".DoSomething(aParam: T);
var a:integer;
begin
a:=integer((@aParam)^); // Bug here, hello to the EDX register
….
end;

Asm code equavalent of assign op
…
Inner SEH FRAME

push $0046c650
push dword ptr fs:[eax]
mov fs:[eax],esp

a:=integer((@aParam)^); // Bug here, hello to the EDX register

Problem instruction - Assign OP

After this one we catch an Exception.

lea eax,quiet_dl

This instruction isn’t executed.
mov ebx,[eax]

Second.

Today I was trying to improve my implementation of C# Yield operator implementation in native Delphi.
You can find my free time research on santonov.blogspot.com.

But I encountered a problem that is an unabitility to use any asm chunks in parameterized classes.

Third. Recall to operators in parameterized classes.

You suggest an interestring solution.

Implicit(T):integer;

Or may be even Implicit(T):U.

And what about +,-,*,/ …. with different combination of all parameterized types.

That about the expression?

(U+T*Z-V*10*(cast to V) (U))/U

Class implementer may to be at a loss by this expression.

How many operator constraints has programmer to declare?

Why would not this responsibility move to compiler?

It is a power of native code.

And constraints is necessity of .Net to generate safe code.

But, in any case your idea is very good.