Tuesday, May 29, 2012

C# Generics & Arithmetic Operators

In this post we will be discussing using arithmetic operators with C# Generics. Basically C# does static type checking for operators. If compiler cannot determine the actual types it is being applied to, then it results in an error stating that the operator cannot be applied for the type. In the case of generics, since the type is not known, it cannot apply the relevant operator to the expression. In the following, we are using an arithmetic operator '+' to an instance of a type argument and you can see that the compiler doesn't seem to like it.

In the following discussion, we would try to find a solution so that we could use the arithmetic operators in this case.

Let's introduce a generic interface ICalculator<T>. It behaves like a simple calculator and exposes Add, Subtract, Multiply and Divide on the arguments. The type of argument is the same as the type argument of the generic interface.

The simplest implementation of the interface can be as follows:

This is definitely not a production quality code as there is no error checking. But this minimizes the noise keeping focus on the topic under discussion. Now let's try to build the code. As expected compiler doesn't seem to like these arithmetic operators applied to operands of type as Type Arguments. And the compiler is right. It can not do static type checking of these operators as the actual type is not known at compile time.

As discussed in the previous post, generics support various constraints. Based on these constraints, the compiler allows the type arguments to be used in a certain way. The list of constraints can be found here: [http://msdn.microsoft.com/en-us/library/d5x73970%28v=vs.100%29]. There is no such constraint where we could specify that "T" is a numeric type. The compiler shouldn't have any issues in that case as the arithmetic operators can be used with numeric types. The other problem is that even if we were able to specify any such constraint, there is no super type that all of these numeric types inherit from. They are not even reference types that they support inheritence.

One argument would be to avoid using the Generics altogether and provide the Calculator implementation using concrete type. But this would really be cumbersome to implement separate type for each numeric type. Please don't hit me to say that :)

Basically we are not focusing on the main issue when try to find the solution. Static Type checking for operators is the main issue. That is why we are not able to use these operators with these operands. So, the solution could be provided by using "dynamic". Using dynamic would create an expression tree for the expression which would be resolved at runtime. Please refer to this post where we have discussed how DLR uses expresion trees [http://www.shujaat.net/2012/05/expression-trees-part-i.html]. Let's update the Calculator implementation as follows:

Now the code should build successfully. We can use the calculator as follows:

Since there is no type checking at compile time, we can run into issues like these when runtime cannot find the operator overloaded for any type used as type argument.

But this is a general issue possible with use of dynamic feature which can be addressed through various checks with the use of dynamic. There is already enough material on this already.

Download Code:

No comments: