.NET generics & the .NET framework: not generic enough?

[Andreas Huber]

What follows is a discussion of my experience with .NET generics & the
..NET framework (as implemented in the Visual Studio 2005 Beta 1),
which leads to questions as to why certain things are the way they
are.

***** Summary & Questions *****

In a nutshell, the current .NET generics & .NET framework make it
sometimes difficult or even impossible to write truly generic code.
For example, it seems to be impossible to write a truly generic
Complex class or a truly generic Matrix class (see below for details).
Since this seems to be due to a combination of shortcomings in both
the .NET framework and the generics mechanism, I have two questions:

1. Why does the overload resolution mechanism only consider overloads
with generic parameters when we call a function with a generic
argument? If it considered other overloads as well, this would allow
us to work around classes that do not implement the proper generic
interfaces (see below for an example).

2. Why do .NET framework classes for primitive types (Byte, Int32,
Decimal, Double, etc.) not implement an interface like IArithmetic< T

(see below for an example)?
In isolation, neither of these limitations would be a big problem, as
we could easily work around them. However, their combination seems to
make it impossible to use generics for some tasks.

***** Discussion *****

Let us try to develop a generic Complex class in C# with generics. Our
(admitedly naive) first shot would be as follows:

public struct Complex< T >
{
T real;
T imag;

public Complex( T real, T imag )
{
this.real = real;
this.imag = imag;
}

public static Complex< T > operator +(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
left.real + right.real, left.imag + right.imag );
}

// other operators
}

Trying to compile this yields the following errors:

complex.cs(24,7 ): error CS0019: Operator '+' cannot be applied to
operands of type 'T' and 'T'
complex.cs(24,3 1): error CS0019: Operator '+' cannot be applied to
operands of type 'T' and 'T'

which is fair enough, as we didn't specify any constraints for T.
However, exactly what constraint should we specify to make this work?
After all we want to use our Complex class with primitive types (e.g.
float, double) *and* user-defined types. To make it usable for the
latter is easy enough:

public interface IArithmetic< T >
{
T Add( T other );
// other operations
}

public struct Complex< T > where T : IArithmetic< T >
{
T real;
T imag;

public Complex( T real, T imag )
{
this.real = real;
this.imag = imag;
}

public static Complex< T > operator +(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
left.real.Add( right.real ),
left.imag.Add( right.imag ) );
}

// other operators
}

So far so good, but what do we do to make this work for types that do
not implement our interface, namely framework-supplied ones like
float, double and perhaps decimal? All these types only implement the
interfaces IComparable, IFormattable, IConvertible and IComparable< T. None of these helps us implementing Complex. After some fiddling

around, I came up with the following:

public interface IArithmetic< T >
{
T Add( T other );
}

public struct Complex< T >
{
T real;
T imag;

public Complex( T real, T imag )
{
this.real = real;
this.imag = imag;
}

public static Complex< T > operator+(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
Add( left.real, right.real ),
Add( left.imag, right.imag ) );
}

// other operators

static float Add( float left, float right )
{
return left + right;
}

// other overloads for double, etc.

// overload for all other types
static U Add< U >( U left, U right )
{
// implementation postponed
}
}

I was hoping that the two Add overloads would allow me to discriminate
between primitive, framework-supplied types and user-supplied types.
This does not work, the generic overload is also selected when I add
two Complex< float > objects.
I then tried various other ways to discriminate between types, but
none of them led to anything more interesting than the above. It seems
that when you call a function with an argument of generic type that
the parameter of the function accepting said argument inevitably also
needs to be a generic type. I.e. the second Add overload can take two
forms:

static T Add( T left, T right )

or

static U Add< U >( U left, U right )

It seems that no matter which form we choose, no other Add overloads
(e.g. for float, etc.) will ever be considered.

[Mattias Sjögren]

Andreas,

1. Why does the overload resolution mechanism only consider overloads
with generic parameters when we call a function with a generic
argument?
Because method resolution is done at compile time, but the actual
generic argument isn't known until runtime.

2. Why do .NET framework classes for primitive types (Byte, Int32,
Decimal, Double, etc.) not implement an interface like IArithmetic< T

(see below for an example)?

I don't know why. It's a fairly common request, but I don't think it
would be the best solution. What's really missing here are operator
contraints. Hopefully that's something they can add support for in
future versions of the framework.

Implementing an IArithmetic type of interface as a workaround would
have other consequences. One major problem I see with it is the fact
that casting a value type to an implemented interface requires boxing.
All that boxing would be terrible for performance if you did a
signinficant amount of calculations.

So far so good, but what do we do to make this work for types that do
not implement our interface, namely framework-supplied ones like
float, double and perhaps decimal?

If you change the IArithmetic contract so that it can be implemented
by a type separate from the type it operates on, like this

interface IArithmetic<T>
{
T Add(T left, T right);
...
}

You could write implementations for ints and doubles and such yourself
(the set of primitive value types is after all limited), and then get
the IArithmetic implementation through a factory. Something like
public struct Complex< T > where T : new()
{
T real;
T imag;
static IArithmetic<T> arith;

static Complex() {
if ( typeof(T).IsPri mitive )
arith = ArithmeticFacto ry.GetPrimitive Arithmetic<T>() ;
else if ( typeof(IArithme tic<T>).IsAssig nableFrom(typeo f(T)) )
arith = new T() as IArithmetic<T>;
else
throw new TypeLoadExcepti on(
"T must be primitive or implement IArithmetic<T>" );
}

public static Complex< T > operator+(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
arith.Add( left.real, right.real ),
arith.Add( left.imag, right.imag ) );
}
}

static class ArithmeticFacto ry
{
private class Int32Arithmetic : IArithmetic<int > {
public int Add(int left, int right) { return left + right; }
}

public static IArithmethic GetPrimitiveAri thmetic<T>()
{
// You could use a more efficient lookup here, and make the
// implementations singletons. This is just for demonstration
if ( typeof(T) == typeof(int) )
return (IArithmetic<T> )new Int32Arithmetic ();
... and so on for other primitive types ...
}
}
This avoids the boxing overhead, but it's of course a lot more typing.
And since the IArithmetic implementation is now external to to the
operands, they can't access private instance data which may or may not
be a problem.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Andreas Huber]

Hi Mattias,

1. Why does the overload resolution mechanism only consider overloads
with generic parameters when we call a function with a generic
argument?
Because method resolution is done at compile time, but the actual
generic argument isn't known until runtime.

I guess it depends what you call compile time and runtime. In .NET you
actually have two compile times: Firstly, the generic class (C#, VB, etc.)
is compiled into MSIL. Later (at runtime), the MSIL is compiled to native
code. As far as I can see, under certain circumstances, it would be possible
to postpone overload resolution for function calls involving generic
parameters until this second compilation stage.

2. Why do .NET framework classes for primitive types (Byte, Int32,
Decimal, Double, etc.) not implement an interface like IArithmetic< T

(see below for an example)?
I don't know why. It's a fairly common request, but I don't think it
would be the best solution. What's really missing here are operator
contraints. Hopefully that's something they can add support for in
future versions of the framework.

Indeed, operator constraints would be the best solution.
Implementing an IArithmetic type of interface as a workaround would
have other consequences. One major problem I see with it is the fact
that casting a value type to an implemented interface requires boxing.
All that boxing would be terrible for performance if you did a
signinficant amount of calculations.
Unless I'm mistaken the whole point of interfaces in generics is that you
don't have to pay that boxing overhead. The interface is only there to
ensure that your type meets certain requirements. The generic code then
directly deals with objects of the type it was instantiated with and never
ever has to box anything.
So far so good, but what do we do to make this work for types that do
not implement our interface, namely framework-supplied ones like
float, double and perhaps decimal?

If you change the IArithmetic contract so that it can be implemented
by a type separate from the type it operates on, like this

interface IArithmetic<T>
{
T Add(T left, T right);
...
}

You could write implementations for ints and doubles and such yourself
(the set of primitive value types is after all limited), and then get
the IArithmetic implementation through a factory. Something like

<code snipped>
This avoids the boxing overhead, but it's of course a lot more typing.
And since the IArithmetic implementation is now external to to the
operands, they can't access private instance data which may or may not
be a problem.

Ok, I forgot to mention why I want to use generics for a hypothetical
Complex/Matrix library. One of the main reasons is to achieve performance
that is at least comparable with C++. I believe this won't be possible if we
runtime dispatch for each operation on Complex/Matrix elements.

Regards,

Andreas

[Jay B. Harlow [MVP - Outlook]]

Mattias,

All that boxing would be terrible for performance if you did a
signinficant amount of calculations.
I've found when I use IComparable<T> for a value type (System.Int32 for
example), there is no boxing going on, why would IArithmetic<T> cause boxing
to go on?

As Andreas states, is not that the whole point of the IComparable<T>
interface? to avoid boxing!

I agree true operator constraints would probably be the best, Not entirely
sure how they would work as + on Int32 is a IL opcode, while + on
System.Decimal is an overloaded operator, would an operator contraint
require an overloaded operator, requiring Int32 to offer the overloaded
operators, although + for Int32 is already an IL opcode?

I don't see why IArithmetic<T> could not be easily implemented today... (I'm
sure there are reasons ;-)

I had not thought using a Factory method like that: My thought, if I needed
IArithmetic<T> was to create proxy classes for type built-in types similar
to the System.Data.Sql Types types, my class would have the IArithmetic<T>
constraint, but you would pass it a ArithmeticInt32 instead of an Int32.

interface IArithmetic<T>
{
T Add(T other);
...
}

struct ArithmeticInt32 : IArithmetic<Int 32>
{
Int32 value;

Int32 Add(Int32 other)
{
return value + other;
}

...

// implicit conversions possibly
}

struct ArithmeticDoubl e : IArithmetic<Dou ble> {...}

public struct Complex<T> : where T : Arithmetic<T>
{
}

Complex<Arithme ticInt32> ci;
Complex<Arithme ticDouble> cd;

Of course Complex<T> would possible implement IArithmetic<T> also for
itself....

My only concern with IArithmetic<T> is should there be a single interface
with all math "operators" , or should there be individual interfaces, such as
IAdd<T>, ISubtract<T>, IMultiply<T>, IDivide<T>, and so on that
IArithmetic<T> inherits from? As I can see creating generic classes that
need to support addition but (TimeSpan) but Multiplication does not make
sense...

Just a thought
Jay

"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. .. Andreas,

1. Why does the overload resolution mechanism only consider overloads
with generic parameters when we call a function with a generic
argument?

Because method resolution is done at compile time, but the actual
generic argument isn't known until runtime.

2. Why do .NET framework classes for primitive types (Byte, Int32,
Decimal, Double, etc.) not implement an interface like IArithmetic< T

(see below for an example)?

I don't know why. It's a fairly common request, but I don't think it
would be the best solution. What's really missing here are operator
contraints. Hopefully that's something they can add support for in
future versions of the framework.

Implementing an IArithmetic type of interface as a workaround would
have other consequences. One major problem I see with it is the fact
that casting a value type to an implemented interface requires boxing.
All that boxing would be terrible for performance if you did a
signinficant amount of calculations.

So far so good, but what do we do to make this work for types that do
not implement our interface, namely framework-supplied ones like
float, double and perhaps decimal?

If you change the IArithmetic contract so that it can be implemented
by a type separate from the type it operates on, like this

interface IArithmetic<T>
{
T Add(T left, T right);
...
}

You could write implementations for ints and doubles and such yourself
(the set of primitive value types is after all limited), and then get
the IArithmetic implementation through a factory. Something like
public struct Complex< T > where T : new()
{
T real;
T imag;
static IArithmetic<T> arith;

static Complex() {
if ( typeof(T).IsPri mitive )
arith = ArithmeticFacto ry.GetPrimitive Arithmetic<T>() ;
else if ( typeof(IArithme tic<T>).IsAssig nableFrom(typeo f(T)) )
arith = new T() as IArithmetic<T>;
else
throw new TypeLoadExcepti on(
"T must be primitive or implement IArithmetic<T>" );
}

public static Complex< T > operator+(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
arith.Add( left.real, right.real ),
arith.Add( left.imag, right.imag ) );
}
}

static class ArithmeticFacto ry
{
private class Int32Arithmetic : IArithmetic<int > {
public int Add(int left, int right) { return left + right; }
}

public static IArithmethic GetPrimitiveAri thmetic<T>()
{
// You could use a more efficient lookup here, and make the
// implementations singletons. This is just for demonstration
if ( typeof(T) == typeof(int) )
return (IArithmetic<T> )new Int32Arithmetic ();
... and so on for other primitive types ...
}
}
This avoids the boxing overhead, but it's of course a lot more typing.
And since the IArithmetic implementation is now external to to the
operands, they can't access private instance data which may or may not
be a problem.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Jay B. Harlow [MVP - Outlook]]

Doh!

struct ArithmeticInt32 : IArithmetic<Int 32>
should be
struct ArithmeticInt32 : IArithmetic<Ari thmeticInt32>
Jay

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** **********@TK2M SFTNGP10.phx.gb l... Mattias,

All that boxing would be terrible for performance if you did a
signinficant amount of calculations.
I've found when I use IComparable<T> for a value type (System.Int32 for
example), there is no boxing going on, why would IArithmetic<T> cause

boxing to go on?

As Andreas states, is not that the whole point of the IComparable<T>
interface? to avoid boxing!

I agree true operator constraints would probably be the best, Not entirely
sure how they would work as + on Int32 is a IL opcode, while + on
System.Decimal is an overloaded operator, would an operator contraint
require an overloaded operator, requiring Int32 to offer the overloaded
operators, although + for Int32 is already an IL opcode?

I don't see why IArithmetic<T> could not be easily implemented today... (I'm sure there are reasons ;-)

I had not thought using a Factory method like that: My thought, if I needed IArithmetic<T> was to create proxy classes for type built-in types similar
to the System.Data.Sql Types types, my class would have the IArithmetic<T>
constraint, but you would pass it a ArithmeticInt32 instead of an Int32.

interface IArithmetic<T>
{
T Add(T other);
...
}

struct ArithmeticInt32 : IArithmetic<Int 32>
{
Int32 value;

Int32 Add(Int32 other)
{
return value + other;
}

...

// implicit conversions possibly
}

struct ArithmeticDoubl e : IArithmetic<Dou ble> {...}

public struct Complex<T> : where T : Arithmetic<T>
{
}

Complex<Arithme ticInt32> ci;
Complex<Arithme ticDouble> cd;

Of course Complex<T> would possible implement IArithmetic<T> also for
itself....

My only concern with IArithmetic<T> is should there be a single interface
with all math "operators" , or should there be individual interfaces, such as IAdd<T>, ISubtract<T>, IMultiply<T>, IDivide<T>, and so on that
IArithmetic<T> inherits from? As I can see creating generic classes that
need to support addition but (TimeSpan) but Multiplication does not make
sense...

Just a thought
Jay

"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

Andreas,

1. Why does the overload resolution mechanism only consider overloads
with generic parameters when we call a function with a generic
argument?

Because method resolution is done at compile time, but the actual
generic argument isn't known until runtime.

2. Why do .NET framework classes for primitive types (Byte, Int32,
Decimal, Double, etc.) not implement an interface like IArithmetic< T
> (see below for an example)?

I don't know why. It's a fairly common request, but I don't think it
would be the best solution. What's really missing here are operator
contraints. Hopefully that's something they can add support for in
future versions of the framework.

Implementing an IArithmetic type of interface as a workaround would
have other consequences. One major problem I see with it is the fact
that casting a value type to an implemented interface requires boxing.
All that boxing would be terrible for performance if you did a
signinficant amount of calculations.

So far so good, but what do we do to make this work for types that do
not implement our interface, namely framework-supplied ones like
float, double and perhaps decimal?

If you change the IArithmetic contract so that it can be implemented
by a type separate from the type it operates on, like this

interface IArithmetic<T>
{
T Add(T left, T right);
...
}

You could write implementations for ints and doubles and such yourself
(the set of primitive value types is after all limited), and then get
the IArithmetic implementation through a factory. Something like
public struct Complex< T > where T : new()
{
T real;
T imag;
static IArithmetic<T> arith;

static Complex() {
if ( typeof(T).IsPri mitive )
arith = ArithmeticFacto ry.GetPrimitive Arithmetic<T>() ;
else if ( typeof(IArithme tic<T>).IsAssig nableFrom(typeo f(T)) )
arith = new T() as IArithmetic<T>;
else
throw new TypeLoadExcepti on(
"T must be primitive or implement IArithmetic<T>" );
}

public static Complex< T > operator+(
Complex< T > left, Complex< T > right )
{
return new Complex< T >(
arith.Add( left.real, right.real ),
arith.Add( left.imag, right.imag ) );
}
}

static class ArithmeticFacto ry
{
private class Int32Arithmetic : IArithmetic<int > {
public int Add(int left, int right) { return left + right; }
}

public static IArithmethic GetPrimitiveAri thmetic<T>()
{
// You could use a more efficient lookup here, and make the
// implementations singletons. This is just for demonstration
if ( typeof(T) == typeof(int) )
return (IArithmetic<T> )new Int32Arithmetic ();
... and so on for other primitive types ...
}
}
This avoids the boxing overhead, but it's of course a lot more typing.
And since the IArithmetic implementation is now external to to the
operands, they can't access private instance data which may or may not
be a problem.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Andreas Huber]

Hi Jay,

Jay B. Harlow [MVP - Outlook] wrote:

I had not thought using a Factory method like that: My thought, if I
needed IArithmetic<T> was to create proxy classes for type built-in
types similar to the System.Data.Sql Types types, my class would have
the IArithmetic<T> constraint, but you would pass it a
ArithmeticInt32 instead of an Int32. [code snipped]

Implementing proxies is of course always an option but I think it is a
really bad one. After all generics should help us to reduce the amount of
code, not force us to produce more of it!
My only concern with IArithmetic<T> is should there be a single
interface with all math "operators" , or should there be individual
interfaces,

Agreed, IArithmetic< T > would be too inflexible. So, operator constraints
would probably be the best solution.

Regards,

Andreas

[Jay B. Harlow [MVP - Outlook]]

Andreas,

Implementing proxies is of course always an option but I think it is a
really bad one. I sincerely hope you did not mean "really bad one" as bad as it sounds. :-|

I agree its not necessarily a good option. However! In light of not having
Operator constraints and the base types (Int32) not supporting an
IArithmetic<T> directly, I find it a reasonable good workaround.

I would love to hear a "better" work around, that can implemented today, as
I have a couple of places where doing math generically would be useful...

A second alternative I've wondered how usable would be Generic Delegates,
only I'm not sure how easy they would be to use in this case.

Action<T> is an example of a generic delegate:
http://lab.msdn.micros oft.com/library/default.asp?url =/library/en-us/cpref/html/T_System_Action `1.asp

Just a thought
Jay

"Andreas Huber" <ah****@gmx.net > wrote in message
news:40******** **@news.bluewin .ch... Hi Jay,

Jay B. Harlow [MVP - Outlook] wrote:

I had not thought using a Factory method like that: My thought, if I
needed IArithmetic<T> was to create proxy classes for type built-in
types similar to the System.Data.Sql Types types, my class would have
the IArithmetic<T> constraint, but you would pass it a
ArithmeticInt32 instead of an Int32.

[code snipped]

Implementing proxies is of course always an option but I think it is a
really bad one. After all generics should help us to reduce the amount of
code, not force us to produce more of it!

My only concern with IArithmetic<T> is should there be a single
interface with all math "operators" , or should there be individual
interfaces,

Agreed, IArithmetic< T > would be too inflexible. So, operator constraints
would probably be the best solution.

Regards,

Andreas

[Daniel O'Connell [C# MVP]]

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:Op******** *****@TK2MSFTNG P12.phx.gbl...

Andreas,

Implementing proxies is of course always an option but I think it is a
really bad one.

I sincerely hope you did not mean "really bad one" as bad as it sounds.
:-|

I agree its not necessarily a good option. However! In light of not having
Operator constraints and the base types (Int32) not supporting an
IArithmetic<T> directly, I find it a reasonable good workaround.

I would love to hear a "better" work around, that can implemented today,
as
I have a couple of places where doing math generically would be useful...

A second alternative I've wondered how usable would be Generic Delegates,
only I'm not sure how easy they would be to use in this case.\

Well, you *could* use dynamic methods, assuming you have the permissions:
public delegate T Operator<T>(T a,T b);
public static Operator<T> CreateAddOperat or<T>()
{
DynamicMethod method = new DynamicMethod(" AddMethod" +
typeof(T).ToStr ing(), typeof(T), new Type[] { typeof(T), typeof(T) },
typeof(Operator Factory));
ILGenerator ilg = method.GetILGen erator();
ilg.Emit(OpCode s.Ldarg_0);
ilg.Emit(OpCode s.Ldarg_1);
if (typeof(T).IsPr imitive)
{

ilg.Emit(OpCode s.Add);

}
else
{
//do reflection on typeof(T) and generate op_Add code.
MethodInfo info = typeof(T).GetMe thod("op_Additi on", new Type[] {
typeof(T), typeof(T) }, null);
ilg.EmitCall(Op Codes.Call, info, null);
}
ilg.Emit(OpCode s.Ret);

return (Operator<T>)me thod.CreateDele gate(typeof(Ope rator<T>));
}

I've only tested int and decimal, but it does work for those two. This
doesn't handle multiple add types(although you could write one). The biggest
problem is DynamicMethods have some permission requirements and my not be
emittable in some situations. I'm not sure how the security works with
regards to them however.

[Andreas Huber]

> I sincerely hope you did not mean "really bad one" as bad as it

sounds. :-|
Sorry, that was not my intention. I didn't write "really bad" because I
think it's a bad idea to solve the problem this way (under the
circumstances, it might even be the best way). I wrote it because I had high
hopes that .NET generics will be a powerful tool to design our programs
better and avoid most of the code duplication that's currently necessary.
I'm a bit disappointed to see that I was hoping for too much. Generics do
solve a few problems (namely performance and compile-time correctness stuff)
but they still only partially solve that nasty code duplication problem. I
also think the guys at Microsoft must be aware of this but they did not do
something about it. I'm sure they have their reasons but it would be nice to
know them (including easy work-arounds we might be missing).
A second alternative I've wondered how usable would be Generic
Delegates,
only I'm not sure how easy they would be to use in this case.

Action<T> is an example of a generic delegate:

http://lab.msdn.micros oft.com/library/default.asp?url =/library/en-us/cpref/html/T_System_Action `1.asp

Generic delegates might indeed offer a way to specify how to perform the
operations of the generic type. But then again the same can be done with an
interface:

interface IArithmeticOps< T >
{
T Add( T left, T right );
// other ops
}

struct Complex< T, Ops > where U : IArithmeticOps< T >, new()
{
static Ops ops = new Ops();
T real;
T imag;

// ...

public static T operator+( T left, T right )
{
return new Complex< T, Ops >(
ops.Add( left.real, right.real ),
ops.Add( left.imag, right.imag ) );
}
}

Regards,

Andreas

[Jay B. Harlow [MVP - Outlook]]

Daniel,
Maybe its late ;-)

By the time I write all the dynamic methods for all the types I would want,
wouldn't it be quicker or at least just as easy to simply write a code
generator based on the CodeDom to spit out all the Arithmetic proxy classes
based on what I stated??

Otherwise I'm keeping the code snippet it may come in handy for other
things...

Jay

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:OR******** ******@TK2MSFTN GP11.phx.gbl...

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:Op******** *****@TK2MSFTNG P12.phx.gbl...

Andreas,

Implementing proxies is of course always an option but I think it is a
really bad one. I sincerely hope you did not mean "really bad one" as bad as it sounds.
:-|

I agree its not necessarily a good option. However! In light of not having Operator constraints and the base types (Int32) not supporting an
IArithmetic<T> directly, I find it a reasonable good workaround.

I would love to hear a "better" work around, that can implemented today,
as
I have a couple of places where doing math generically would be useful...
A second alternative I've wondered how usable would be Generic Delegates, only I'm not sure how easy they would be to use in this case.\

Well, you *could* use dynamic methods, assuming you have the permissions:
public delegate T Operator<T>(T a,T b);
public static Operator<T> CreateAddOperat or<T>()
{
DynamicMethod method = new DynamicMethod(" AddMethod" +
typeof(T).ToStr ing(), typeof(T), new Type[] { typeof(T), typeof(T) },
typeof(Operator Factory));
ILGenerator ilg = method.GetILGen erator();
ilg.Emit(OpCode s.Ldarg_0);
ilg.Emit(OpCode s.Ldarg_1);
if (typeof(T).IsPr imitive)
{

ilg.Emit(OpCode s.Add);

}
else
{
//do reflection on typeof(T) and generate op_Add code.
MethodInfo info = typeof(T).GetMe thod("op_Additi on", new Type[] {
typeof(T), typeof(T) }, null);
ilg.EmitCall(Op Codes.Call, info, null);
}
ilg.Emit(OpCode s.Ret);

return (Operator<T>)me thod.CreateDele gate(typeof(Ope rator<T>));
}

I've only tested int and decimal, but it does work for those two. This
doesn't handle multiple add types(although you could write one). The

biggest problem is DynamicMethods have some permission requirements and my not be
emittable in some situations. I'm not sure how the security works with
regards to them however.