Linq Expressions – Calculating with generics

You can find the full code for this post here: 

The .NET framework lacks support for calculating with generic types.
There is no way to ensure that a generic type supports operations like Add, Sub, Div and Mul etc.

More about the problem can be found here:

“They are not. There have been a few threads on this subject before,
and the conclusion was that it is impossible to perform any of the
built-in mathematical operations on generic types.”

Many have tried to come up with solutions for calculating with generic types, most of them based on provider solutions where you have to provide a “Calculator” class for each type that you want your generic class to support.
Quirky to say the least..

One such solution exists here:

And don’t get me wrong, I’m NOT saying that those are bad implementations, it was just not possible to solve this in any clean way before.

But now when we have Linq Expression Trees we can solve this. and do it quite nicely.

We can produce delegates that performs the math operations for us.
Like this:

private static Func<T, T, T> CompileDelegate 
 (Func<Expression,Expression,Expression> operation) 
    //create two inprameters 
    ParameterExpression leftExp = 
 Expression.Parameter(typeof(T), "left");                   

    ParameterExpression rightExp = 
 Expression.Parameter(typeof(T), "right");                   

    //create the body from the delegate that we passed in 
    Expression body = operation (leftExp,rightExp);              

    //create a lambda that takes two args of T and returns T 
    LambdaExpression lambda = 
Expression.Lambda(typeof(Func<T, T, T>), body, leftExp, rightExp);              

     //compile the lambda to a delegate 
    // that takes two args of T and returns T 
    Func<T, T, T> compiled = (Func<T, T, T>)lambda.Compile(); 
    return compiled; 

 We can now call this method and get our typed delegates for math operations:

private static readonly Func<T, T, T> Add = 

And this is pretty much all the magic we need to solve the problem with generics and math operations.
I have created a generic class that support all the standard operators based on this approach.

You can find the full code here:

This makes it possible to use code like this:

private static T DoStuff<T>(T arg1, T arg2, T arg3) 
    if (!Number<T>.IsNumeric) 
        throw new Exception("The type is not numeric");       

    Number<T> v1 = arg1; 
    Number<T> v2 = arg2; 
    Number<T> v3 = arg3; 
    return v1 * v2 - v3; //not possible with normal generics 

OK that was a very naive example, but atleast you can see that it is possible to perform calcualtions on the generic type.
So no more provider based calculator classes, just fast typed delegates :-)


For those who are interested in this kind of stuff, there is a project called MiscUtil that can be found here:

They do the same stuff as in this article, but much more complete and polished code than my sample.


Linq Expressions – Access private fields

In this post I will show how you can use Linq Expressions to access private(or public) class fields instead of using Reflection.FieldInfo.

Normally when you want to access a field by its name on a type you have to resort to reflection.
You will end up with something like this:

FieldInfo field = MyType.GetField("someField",BindingFlags.NonPublic | .... ); 
object res = field.GetValue (MyObj);

This suffers from allot of drawbacks, it’s ugly, it’s untyped and its horribly slow to access data via FieldInfo.

Instead of playing around with FieldInfo, you can now use Linq Expressions to build a typed delegate that does this for you.

Here is how you do it:

public static Func<T,R> GetFieldAccessor<T,R>(string fieldName) 
  ParameterExpression param = 
  Expression.Parameter (typeof(T),"arg");  

  MemberExpression member = 
  Expression.Field(param, fieldName);   

  LambdaExpression lambda = 
  Expression.Lambda(typeof(Func<T,R>), member, param);   

  Func<T,R> compiled = (Func<T,R>)lambda.Compile(); 
  return compiled; 

So what does this method do?
The first line in it will create a parameter expression, that is an argument that will be passed into our delegate eventually.

The next line creates a member expression, that is the code that access the field we want to use.
If you look at the code, you will see that we create an expression that access fields (Expression.Field) and that the first arg is the parameter we created before and the 2nd arg is the name of the field we want to access.
So what it does is that it will access the named field on the object that we pass as an argument to our delegate.

The 3rd line is where we create our lambda expression.
The lambda expression is the template for our delegate, we describe what we want to pass into it and what we want to get out of it.

The last part of the code will compile our lambda into a typed delegate: Func<T,R>, where T is the type of the argument we want to pass it and R is the type of the result we want to get out of it.

Here is an example on how to use this code:

Person person = new Person(); 
person.FirstName = "Roger"; 
var getFirstName = GetFieldAccessor<Person,string> ("firstName"); 
//typed access via delegate 
string result = getFirstName(person);

Also do note that the “firstName” arg is the name of the field we want to access, not the property that I access in the sample.

This approach is also much faster than Reflection.FieldInfo.
I made a little benchmark where I accessed the same field a million times.

The Reflection.FieldInfo approach took 6.2 seconds to complete.
The Compiled lambda approach took 0.013 seconds to complete.
That’s quit a big difference.

So with this approach you can optimize your old reflection code and get some serious performance gains..

Well, that’s all for now.



kick it on

See also:

Linq to NPersist to MS Access

I’ve finally seen my own Linq support Live :-P
Untill now I’ve only been emitting NPath quereis and verified that NPath is correct.

The reason I havent tested it live untill now is that I only have my gaming machine to develop on atm. the dev machine is dead.

Anyway, I’m trying it against NWind MS Access DB right now and it works like a charm.
I can even run fairly complex queries, even if it takes a bit of time on MS Access.

var res = from cust in ctx.Repository<Customer>() 
                 order => order.OrderDetails.Sum( 
                     detail => detail.UnitPrice * detail.Quantity 
                                                ) > 1000) 
          orderby cust.CompanyName 
          select cust;

This lists all customers that have atleast one order with the order total of 1000$.
I was a bit nervous before and thought that maybe it will fail.. even though the NPath looks correct and the NPath to SQL generator have been working fine for the last 3 years ;-)

Typed factories in C#3 – V2

This is a follow up on my previous post:

 I’ve added support for property and field initializers.
This makes it possible to call your factory like this:

Person person = MyFactory.Create(() => new Person("Roger", "Alsing") { 
    Age = 32, 
    SomeIntField = 4, 
    SomeIntArray = new int[]{1,2,3} 

You can find the code for the improved factory class here:
templatedfactorycs.txt   (WordPress don’t like .cs files)


Typed factories in C#3 – Managed “new”

One thing that always bothered me with factory methods in earlier versions of C# is that the only way to make a generic factory method, you have to pass in all the constructor args as an object array.

A normal factory method might look something like this:

public T Create<T>(params object[] args) 

And you invoke it with:

Person person = MyFactory.Create<Person>(arg1,arg2,arg3);

When doing so, you have no clue what args you can pass to it, there is no intellisense here, we only know that our Create method takes a dynamic numer of args.

So wouldn’t it be sweet if we could make a factory that knows what args you can pass to it?
I think so, and I found a solution for it today.

I solved it like this:

Person person = MyFactory.Create(() => new Person("Roger","Alsing"));

As you see, instead of passing an object array to my create method, I pass it a lambda expression.
The Create method can then examine the expression tree from the lambda, and do whatever it want with the parameters.

The code for dealing with this looks like this:

static T Create<T>(Expression<Func<T>> exp) 
    LambdaExpression lambda = exp as LambdaExpression; 
    NewExpression body = lambda.Body as NewExpression;                 
    List<object> argsList = new List<object>(); 
    foreach (var arg in body.Arguments) 
        //create a lambda to wrap up the expression for "arg" 
        LambdaExpression argLambda = Expression.Lambda(arg); 
        //compile the lambda 
        var argDel = argLambda.Compile(); 
        //get the arg value by invoking the compiled lambda 
        object argValue = argDel.DynamicInvoke(); 
        //add the raw value to the arg list 
    object[] argsArr = argsList.ToArray();     
    //this is where you might want to modify. 
    //eg, make it create some proxy type instead 
    //this is an naive example so I will just create an instance 
    //of the original type and return it.. 
    T instance = (T)Activator.CreateInstance(typeof(T), argsArr); 
    return instance; 

This way I could make typed factory calls for eg. NAspect or NPersist and let the factory return an AOP proxy that is instanced with the parameters from the lambda expression.

Or you could use it in order to describe different singletons, create singletons based on the inparams.
Patrik Löwendahl blogged about singleton patterns today
You can do the same with this approach, but with the benefit that you get typed inparams for the constructor.

You could say that this becomes a form of managed “new”, where you can write a “new” expression and benefit from intellisense and all that, and still be able to override the “new” and return other types or whatever you want.

Hope you like it :-)

An improved version of this with support for property/field initializers can now be found at:

More Linq support for NPersist

I’ve added a bit more Linq support for NPersist today.

The nice thing is that we can “cheat” in our Linq provider, we can transform our Linq queries into NPath queries.
Thus, I don’t have to touch the wicked SQL generation.
I just have to produce valid NPath, which is pretty similair to Linq.

Just look at the following code:

private string ConvertAnyExpression(MethodCallExpression expression) 
    string fromWhere = ConvertExpression(expression.Arguments[0]);     
    if (expression.Arguments.Count == 1) 
        return string.Format("(select count(*) from {0}) > 0", fromWhere); 
        LambdaExpression lambda = expression.Arguments[1] as LambdaExpression; 
        string anyCond = ConvertExpression(lambda.Body); 
        return string.Format("(select count(*) from {0} and {1}) > 0", fromWhere,anyCond); 

Thats all the code that we needed in order to support “list.Any()” and “list.Any(x => ….)”
This both makes the Linq provider easier to build, and it makes it way easier to unit test it too.
We simply have to compare the result with an expected NPath string.
Like this:

string expected = "select * from Customer where ((Customer != ?))"; 
string actual = res.Query.ToNPath(); 
Assert.AreEqual<string>(expected, actual);

So I think we have most of the standard query elements in place now.
I just have to add support for a few more things inside NPath, things like “skip”, “is” etc.

AlbinoHorse – Class Designer

I have published my class designer component at CodePlex.

You can find binaries and sourcecode here:

AlbinoHorse is a Windows Forms control for UML Class diagrams that I’m currently developing.
The idea is to use it in our next version of ObjectMapper. (Mapper tool for ORM entities)