If you still work with windows forms and cannot move all of your projects to WPF, you probably gets annoyed by the limitation of the standard BindingList<T> included in the framework. In an old post I showed how can you create a specialized BindingList<T> to support generic Find() thanks to reflection, but this is not enough.

Another annoying limitation is that BindingList does not support IBindingListView. For those that does not knows this interface, it is the one used by the windows forms binding engine to support filtering and advanced sorting. I think that filtering is a real basic functionality needed by the binding engine, and in fact WPF support for filtering, sorting and grouping, make these operations really a breeze. But BindingList does not offers such a functionality.

My question is: is it possible to inherits from BindingList<T> adding generic filtering support as for the DataView component?. The answer is yes, here is a simple implementation.

public string Filter
{
    get
    {
        return filterClause;
    }
    set
    {
        if (filterClause == value) return;
        filterClause = value;
        DoFilter();
    }
}

This is really simple, I implement the FIlter property with a simple check, if the filterClause changes, I call the DoFilter function.

private Func<T, Boolean> filterPredicate;

private List<T> original = new List<T>();

private void DoFilter()
{
    if (String.IsNullOrEmpty(filterClause))
    {
        Items.Clear();
        original.ForEach(e => Items.Add(e));
    }
    else
    {
        original.Clear();
        original.AddRange(Items);
        Items.Clear();
        filterPredicate = DynamicLinq.ParseToFunction<T, Boolean>(filterClause);
        foreach (T element in original.Where(filterPredicate))
           Items.Add(element);
    }
}

The implementation is based on this standard trick, if a filter is applied I copy all the elements in a temp list, then clear the base.Items list and add again only the elements that satisfies the filter. The big work is done in DynamicLinq.ParseToFunction that takes a string and dynamically compiles a function with that criteria. Here is a simple test showing this class in action.

[Test]
public void TestLogicAnd()
{
    Func<Customer, Boolean> f = DynamicLinq.ParseToFunction<Customer, Boolean>("Name == 'Gian Maria' && Age > 5");
    Assert.That(f(aCustomer), Is.True);
}

Actually I use three main component, a tokenizer that takes a string and separates into token, then I pass the tokenized expression (is a List<String>) to another component that convert the infix form in postfix form (reverse Polish), finally I create an expression from the reverse Polish form, creates a LambdaExpression on it and finally call compile() to make dynamic generation happens. The result is a dynamic generator of LINQ expression from a string. It still misses a lot, you cannot express condition on nested properties and parameter support is still experimental, but the basic is there.

The code is still under development, if you are curios you can check out the repository at http://dotnetmarcheproject.googlecode.com/svn/trunk the code is still in rough form, but if you like it you can give it a shot. The class is the BindingListExt<T>

Alk.

Tags: BindingList IBindingView Dynamic Expression Parser

I’ve incurred in a very stupid bug this afternoon, I run test on a new version of a component and I see that a lot of exceptions are raised about violating unique constraint of a simple strongly typed dataset I use to log information in database.

After a brief look at the code I found that I create new guid with the instruction new Guid(), I was really surprised because I really know that new guid should be created with Guid.NewGuid(). This is indeed caused by the fact that Guid() is a structure and not a class. The following test demonstrate this fact

[Test]
public void CreateGuid()
{
    Assert.That(new Guid(), Is.EqualTo(Guid.Empty));
    Assert.That(Guid.NewGuid(), Is.Not.EqualTo(Guid.Empty));
}

This test will succeeds because Guid is a value type, and he always has a default constructor that can be called to create empty instance of the structure. If you look into the documentation of Guid you can in fact verify that default constructor is not even listed between the valid ones.

This is one of the most annoying difference from reference and value type: value type always have a default constructor and you cannot prevent the user to use it.

alk.

Tags: .net value type

Today I was speaking with a colleague about creating a generic IComparer<T> that is able to compare two object based on a property discovered through reflection. Such object will be very useful to sort or find object inside collection of objects when you work with a domain model. In a domain we usually have a lot of objects such as customer, order, and so on, and it happens to have an homogeneous collection of objects in memory that needs to be sorted. Implementing an IComparer object for each combination of property and type is really boring so it useful to create a class capable to compare object based on reflection. A first implementation of the IComparer<T>::Compare() method could be the following

public int Compare(T x, T y) {    
     PropertyInfo propertyInfo = typeof(T).GetProperty(SortColumn);
     IComparable obj1 = (IComparable)propertyInfo.GetValue(x, null);
     IComparable obj2 = (IComparable)propertyInfo.GetValue(y, null);
     return (obj1.CompareTo(obj2));
}

This implementation works as expected, but it has bad performance, this because it use reflection to find propertyInfo at each calls of the Compare() method. Since we are dealing with homogeneous collections I know in advance that the collection contains objects of a same type, so a better strategy is to cache the MethodInfo related to the GetterPart of the property into the constructor of the comparer object.

   public class GenericIComparer<T> : IComparer<T> {
 
      private readonly MethodBase methodInfo;
 
      internal GenericIComparer(MethodBase methodInfo, Boolean reversed) {
         this.methodInfo = methodInfo;
         mReversed = reversed;
      }
 
      public GenericIComparer(String propname)
         : this(propname, false) {
      }
 
      public GenericIComparer(String propname, bool mReversed) :
         this(typeof(T).GetProperty(propname).GetGetMethod(), mReversed) { }
 
      public bool Reversed {
         get { return mReversed; }
         set { mReversed = value; }
      }
      private Boolean mReversed = false;
 
      #region IComparer<T> Members
 
      public int Compare(T x, T y) {
         IComparable obj1 = (IComparable)methodInfo.Invoke(x, null);
         IComparable obj2 = (IComparable)methodInfo.Invoke(y, null);
 
         Int32 result = (obj1.CompareTo(obj2));
         return mReversed ? -result : result;
      }
 
      #endregion
   }

This version support a property called Reversed that is used to compare in reverse order. As you can see this class grab the methodInfo related to the getter part of the property in the constructor, to reduce calls to GetProperty() function. As you can see this class has an internal constructor that accepts a MethodBase passed from the caller, this is necessary to go a step further into the optimization, a factory class that optimize the creation of GenericIComparer objects.

   public static class GenericComparerFactory {
 
      private readonly static Dictionary<Type, Dictionary<String, RuntimeMethodHandle>> comparers =
         new Dictionary<Type, Dictionary<string, RuntimeMethodHandle>>();
 
      public static GenericIComparer<T> GetComparer<T>(string propertyName, bool reversed) {
         //Check if the type array for this comparer was created.
         if (!comparers.ContainsKey(typeof(T)))
            comparers.Add(typeof(T), new Dictionary<string, RuntimeMethodHandle>());
         if (!comparers[typeof(T)].ContainsKey(propertyName))
            comparers[typeof(T)].Add(
               propertyName, 
               typeof(T).GetProperty(propertyName).GetGetMethod().MethodHandle);
         return (GenericIComparer<T>) new GenericIComparer<T>( 
            MethodInfo.GetMethodFromHandle(comparers[typeof(T)][propertyName]), reversed);
      }
 
      public static GenericIComparer<T> GetComparer<T>(string propertyName) {
         return GetComparer<T>(propertyName);
 
      }
   }

This class hold a dictionary of propertyName, RuntimeMethodHandle objects for each type. The RuntimeMethodHandle is a further optimization to save memory used to store MethodInfo objects. A MethodInfo object is a big object to store into memory, so it has a readonly property called MethodHandle that will return a IntPtr that uniquely identify that method info. The GenericComparerFactory can reduce the use of the memory, storing into the dictionary a IntPtr object, and recreating the MethodInfo object with the GetMethodFromHandle() function of the MethodInfo object only when it is necessary. With these optimization the GenericIComparer has a small memory footprint and maximum performance.

Alk.

 

Yesterday I blogged on a slightly modified version of Ayende code posted here, this makes me reflect on template pattern of the GOF. Template pattern is one of the most useful pattern, and is used when you have a common block of code that is to be repeated in may part with a little customization. In the GOF the intent of the pattern is

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

The original description of the pattern explicitly states that the implementation is made by a template class (usually abstract) and then a series of subclasses, each for a different variation of the algorithm that is to be implemented. C# anonymous delegates are a great way to implement a template pattern even with a static class, without the need to use subclasses or inheritance. The post from Ayende is a great example of this. In his code Ayende creates a base method that accepts a delegate with all the common infrastructure to execute ad Ado.NET DbCommand. In the base static function he creates connection, starts a transaction and creates a command that will be attached to an open connection, then he calls the delegates passed as an argument. With anonymous delegate the caller is able to specify a block of code that logically will be substituted into the inner part of the Template static method. This kind of implementation can also be done in C++ with function pointer, but is definitively not so readable as counterpart in C#.

Alk.

A friend of mine is taking a basic course in computer programming, and actually he is studying the basic of C language. Yesterday he told me that he must do a very simple exercise that will print on screen a triangle like this
XXXXXXXXXX
XXXXXXXXX
XXXXXXXX
And so on. He asked me if I could review his solution before he give his program to the teacher, because he is moving from the old house to a new house and actually he do not have access to a computer to try his solution. This morning I decided to refresh my knowledge of C solving this simple exercise, I must admit that I love C/C++….I cannot explain but they are really fascinating languages (I love assembly language too)

#include “stdio.h”
#include “memory.h”
 
#define NUM_OF_CHARS 10
 
int main() {
   char str[NUM_OF_CHARS + 1];
   int I;
   memset(str, ‘X’, NUM_OF_CHARS);
   for (I = NUM_OF_CHARS; I > 0; –I) {
      str[I] = ‘′; 
      printf(“%sn”, str);
   } 
}

The ability to manage memory of a string is one of the feature that I missed most when I program in C#.

Alk.

Sometimes differences between C# and VB could be subtle, for example consider these very simple two snippets of code, what they will print?

   Sub Main()
      Console.WriteLine(“Result is “ + Sum(Integer.MaxValue, 1))
   End Sub
 
   Public Function Sum(ByVal a As Integer, ByVal b As Integer)
      Return a + b
   End Function

   static void Main(string[] args) {
      Console.WriteLine(“Result is “ + Sum(Int32.MaxValue, 1));
   }
 
   public static Int32 Sum(Int32 a, Int32 b) {
      return a + b;
   }

The first snipped written in VB throws a System.OverflowException, because the result of the operation cannot be stored into an integer value. The behavior of C# can be more surprising because it print Result is -2147483648 showing a result that is clearly wrong. This example shows that VB and C# have very different semantic even for basic operation. But what is the reason for such a different behavior? If we look at MSIL code we can see that VB compiler produces this code

    L_0002: ldarg.1 
    L_0003: add.ovf 
    L_0004: box int32 
 
As you can see the add operation gets translated with opcode add.ofv, where ofv means overflow. This particular operation throws an exception if the result of the operation will result in a overflow. C# generates this snippet.

    L_0002: ldarg.1 
    L_0003: add 
    L_0004: stloc.0

Generated MSIL is different because C# compiler use the add
opcode that will not check for an overflow. The question is: why such different behavior? VB.NET descends from VB6 where all arithmetic operations are checked, so this semantic is maintained even if for .NET version, C# descends from C++ where aritmetic operation does not check for an overflow. The primary reason is efficiency, let’s look at real IA32 code generated by the JIT compiler through disassembly window. This is the assembly generated for the add.ofv opcode (VB).

        Dim result As Integer = a + b
0000002e  mov         eax,ebx 
00000030  add         eax,dword ptr [ebp-40h] 
00000033  jno         0000003A 
00000035  call        79747E72 
0000003a  mov         dword ptr [ebp-44h],eax

After the add operation there is a jno opcode that means “Jump if not overflow“, if the operation will result in a overflow, the instruction does not jump and instruction at offset 35 calls a system routine that will throw the exception. The cost of checking overflow is a branch instruction after every arithmetic operation, for this reason C# compiler does not insert overflow check instruction for arithmetic operation. If you don’t like this, you can force C# compiler to insert overflow checking instruction with checked keyword

checked {
   return a + b;
}ÂÂ

With the checked keyword we can choose to do checked operation only for specific parts of the code. VB is less flexible, because has a compiler operation that will disable overflow check for all the assembly, not showing the granularity of C#.

Alk.

In all type safe languages there is the concept of “casting”, an operation used to specify to the compiler that a variable of a certain Type has to be considered of different Type. Visual Basic has three operators to do a cast: DirectCast, CType and TryCast, each one behaving in a different way from the other. To understand the subtle differences from these three operators lets present a simple example.

   Private Sub DirectCastExample(ByVal obj As Object)
      Console.WriteLine(“string lenght={0}”, DirectCast(obj, String).Length)
   End Sub
 
   Private Sub CTypeExample(ByVal obj As Object)
      Console.WriteLine(“string lenght={0}”, CType(obj, String).Length)
   End Sub
 
   Private Sub trycastExample(ByVal obj As Object)
      Console.WriteLine(“string lenght={0}”, TryCast(obj, String).Length)
   End Sub

   Private Sub Test()
      DirectCastExample(30)
      CTypeExample(30)
      trycastExample(30)
   End Sub

The three instruction of the Test() function give really three different results, the first throws an InvalidCastException, the second writes “string length=2″ and the third throws a NullReferenceException. To understand what is happening we could look at generated MSIL . DirectCast operator is translated with this code

L_0007: castclass string
L_000c: callvirt instance int32 [mscorlib]System.String::get_Length()

DirectCast is translated to castclass opcode, that simply pushes on the stack the object reference to the cast instance. If at run time the instance passed to the function is not a String class an InvalidCastException is thrown. DirectCast can convert if the object is of the exact type, if inherits from the type specified, or if the object implements the interface when the destination type is an interface.

TryCast operator behaves a little different, this is the MSIL generated

L_0007: isinst string
L_000c: callvirt instance int32 [mscorlib]System.String::get_Length()

TryCast use the isinst opcode, that is analogous to castclass, but if the cast is not successful instead of throwing an exception a null value is push on the stack. The third type of cast, CType is not really a cast operator, but instead a conversion operator, even if in a lot of documentation CType is considered to be a cast operator, to understand the difference here is generated MSIL.

L_0007: call string [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Conversions::ToString(object)
L_000c: callvirt instance int32 [mscorlib]System.String::get_Length()

As you can see CType operator calls internally the function ToString() of class Microsoft.VisualBasic.CompilerServices.Conversions, this means that CType does not make a cast, but it makes conversions. The example in fact reveals that when we pass the integer value 30 to the function, this value gets converted to the string “30″ and the code does not throw errors. The annoying issue is that you use CType to convert a variable to a custom type class it defaults to use castclass opcode, since the Microsoft.VisualBasic.CompilerServices.Conversion has methods to convert only to .NET basic types.

Alk.