Generics in .NET 2.0 SUCK

[Ruediger Klaehn]

Sorry about the harsh language, but I have to vent my anger to somebody who
actually understands what I am talking about. Complaining to my girlfriend
is not going to produce any meaningful results other than straining our
relationship...

I just downloaded Visual C# Express Edition to mess with .NET 2.0 generics.
Being a numerically inclined developer, the first thing I wanted to write
was a generic complex number class. I also have some quite large vector and
matrix libraries that I would love to convert to use generics.

Imagine my surprise when I found out that what I want is basically
impossible. I want a complex number class that can work with any basic data
type like so: complex<float>, complex<double> , complex<decimal > and so on.
This is something that is done very often in C++ and one of the main
applications of generics there.

This was my first try (this is only an excerpt):

struct complex<T>
{
public T re,im;
complex<T>(T re,T im)
{
this.re=re;this .im=im;
}
complex<T> Sum(complex<T> a,complex<T> b)
{
return new complex<T>(a.re +b.re,a.im+b.im );
}
}

Something like this would work in C++, since it does not have constraints on
type parameters. But in .NET, when you specify a type parameter without
constraints it is assumed to be a System.Object, which of course does not
have a + operator.

So I thought, probably there is a way to specify a method constraint for T
such that T must have a certain (static) method or a certain operator
method. But the only thing like this is the new() constraint to specify
that a class must have a default constructor.

My second thought was that there might be some interface like IArithmetic.
This is of course complicated by the fact that interfaces can not contain
static methods. But something like

interface IArithmetic<T> {
void Add(T a);
void Subtract(T a);
void Multiply(T a);
void Divide(T a);
}

should do the trick. This would not be very elegant, but quite sufficient.
Given that there is an interface called IComparable<T> this should not be
too much to ask. Maybe there should even be something more granular like

interface IAddable<T> {
void Add(T a);
}

....

interface
IArithmetic<T>: IAddable<T>,ISu btractable<T>,I Multipliable<T> ,IDivisible<T>
{
}

or something. This solution would be similar to the approach taken with
IComparable and IComparable<T>.

But no such interface exists in the System namespace. So I would have to
wrap all the basic data types into structs that actually implement this
interface, like so:

struct ArithmeticInt : IArithmetic<int > {
private int value;
...
}

struct ArithmeticDoubl e : IArithmetic<dou ble> {
private double value;
...
}

But this would be a lot of work and, even worse, would lead to absymal
performance since in my experience the .NET JIT compiler is too dumb to get
rid of the wrapper code.

There are of course some workarounds like having a separate type parameter
for the operations, like this:

struct Complex<T,Ops> where Ops:IArithmetic Ops<T>
{
...
}

But this yields inacceptable performance.

What is really required is a way to specify *method* *constraints* instead
of just interface constraints and the new() constraint.

Another option would be to allow static methods in interfaces and to provide
an IArithmethic interface in the System namespace, but I would prefer the
first option.

Without something like this, generics are only good for typed collections.
Adding so much new syntax and complexity just to make collections faster
and more type safe seems like a waste of time!

[Daniel O'Connell [C# MVP]]

>

Something like this would work in C++, since it does not have constraints
on
type parameters. But in .NET, when you specify a type parameter without
constraints it is assumed to be a System.Object, which of course does not
have a + operator.

So I thought, probably there is a way to specify a method constraint for T
such that T must have a certain (static) method or a certain operator
method. But the only thing like this is the new() constraint to specify
that a class must have a default constructor.

There are some issues with this. The basic types like int, double, etc also
do not have + operators, the + is syntax provided by the compiler, those
types are added using the add instruction. Thus an operator+ constraint
would not do what you wanted.

In the thread Andreas posted I provided a code sample to generate a delegate
for a given type to perform addition, if it was possible. It would have a
performance hit as well, unfortunatly.

To really achieve what you want here, the JIT would have to understand
mathematic operations and generate the proper code for a given generic type.
Its just not so easy as an operator constraint I'm afraid.