Pedram Rezaei's Ramblings : C#

How difficult can it be to overload operator ==?

pedramr — Tue, 20 Nov 2007 23:42:00 GMT

Well apparently very difficult! Today, I read article after article on blogs that suggested weird and wonderful ways of overloading the operator == in C#. Almost all of those were incorrect! So I set myself a challenge to put the record straight:

Before showing you the code, a number of things to remember:

- Overriding operator == is a feature of the C# language and there is no equivalent for it in the Intermediate Language (IL). In other words, the compiler replaces operator == with method calls to the operator overload’s static method.

- Any type that overloads operator == should also overload operator !=

- It only makes sense to override both Equals and GetHashCode methods when overloading operator ==.

- Just to put the record straight, if the GetHashCode of two objects of the same type return the same value, it does NOT mean they are equal!

- Also remember, if you are overloading operator ==, avoid using operator == in its implementation. You will probably get stock in an infinite recursion.

- ReferenceEquals and cast to object should be your friends to avoid recursion and calls to unwanted methods (i.e. You probably don’t want to call operator == overload from the Equals method when evaluating something like obj == null)

- You need to look after null values!

- Use the static Object.Equals method in operator == and != overloads to avoid needing to overload operator == for each inheritor of your class (The instance Equals method is virtual)

So here is an example:

class Rectangle

{

private readonly int _x;

private readonly int _y;

public Rectangle(int x, int y)

{

_x = x;

_y = y;

}

public override int GetHashCode()

{

return _x ^ _y;

}

public override bool Equals(object obj)

{

if (ReferenceEquals(obj, this))

return true;

Rectangle rect = obj as Rectangle;

// need to use ReferenceEquals or cast rect to object

// to avoid a call to the == operator overload below

if (ReferenceEquals(rect, null))

return false;

return rect._x == _x && rect._y == _y;

}

public static bool operator ==

(Rectangle r1, Rectangle r2)

{

// use Object.Equals to avoid needing to to provide == operator

// overload for all inheritors of this class

return Object.Equals(r1, r2);

}

public static bool operator !=

(Rectangle r1, Rectangle r2)

{

return !Object.Equals(r1, r2);

}

Lambda Expressions in C#

pedramr — Sat, 02 Jun 2007 23:10:00 GMT

Before being able to talk about Lambda expressions, I need to wet your appetite by touching on the difference between Expressions and Statements:

i = j;

while (a) f(b);

The above listing is an illustration of 2 statements. As you can see evaluation order is important when it comes to statements.

2 * a + 10 * b

(a - 12) + (b * 2 + 10)

In the above listing, we have 2 expressions. In the second expression we can evaluate either parenthesis first or even both together and that has no effect on the result of the expression. So, evaluation order is unimportant in expressions provided there are no side effects.

You can introduce a side effect in the above expression by for instance overloading the * operator and within its execution change the value of a.

Expressions can be shorter and more concise than their corresponding statements. The example below compares an expression with a number of statements that recreate the effect of the expression:

int r = (2 * a * b + c) * (10 * b * d);

with no expressions:

int r = 2; r *= a; r *= b; r += c;

r *= 10; r *= b; r *= d;

In order to be able to discard statements, expression language must be extended. That is what most functional programming languages have been aiming to achieve. Unfortunately most have miscalculated the need for statements and the programmers’ love for them.

So what are Lambda expressions? And why are they hot again?

Lambda expressions are derived from Church’s λ-calculus theory of compatibility (1941). A lambda expression is a short hand notation for anonymous function definitions:

Integer -> Integer
λ x -> x * 2

The first line of the above listing defines the type of the lambda expression (takes a parameter of type Integer and returns an Integer). The second line is a lambda expression that defines an anonymous function similar to the one below in C# 2.0 (takes a parameter called x and the body of the function return x * 2):

delegate(int x)

{

return x * 2;

}

Here are some more lambda expressions:

λ (x, y) -> x * 10 + y
λ (x, y, z) -> (1/x + 10) * y + z

As you can see, the notation for lambda expressions does not explicitly define the type of parameters and the return value. Therefore in most functional programming languages the type of the function must be specified separately.

Lambda expressions are hot again because of their introduction in C# 3.0 which is due to be released as part of .NET Framework 3.5.

In C# 3.0, according to MSDN books online, a lambda expression is defined as:

“An inline expression or statement block with a concise syntax that can be used wherever a delegate type is expected. For example, you can use a lambda expression as an argument to a method call, to assign a value to a delegate or to define an event handler. Lambdas can be used virtually anywhere that anonymous methods can be used.”

C# 3.0 has a lambda operator (=>) which is functionally identical to the arrow or the dot in λ-calculus. The lambda operator has the same precedence as assignment (=) and is right-associative. In C# 3.0, here are the equivalent lambda-expressions to the ones demonstrated above:

x => x * 2;

(x, y) => x * 10 + y;

(x, y, z) => (1 / x + 10) * y + z;

The above lambda expressions return an instance of a delegate. However the type of the delegate needs to be defined. In System.Linq namespace, there are a number of generic delegates which could be used in order to compose new delegate types for your lambda expressions. These generic delegates are:

public delegate TResult Func<TResult>();
public delegate TResult Func<TArg0, TResult>(TArg0 arg0);
public delegate TResult Func<TArg0, TArg1, TResult>(TArg0 arg0, TArg1 arg1);
public delegate TResult Func<TArg0, TArg1, TArg2, TResult>(TArg0 arg0, TArg1 arg1, TArg2 arg2);
public delegate TResult Func<TArg0, TArg1, TArg2, TArg3, TResult>(TArg0 arg0, TArg1 arg1, TArg2 arg2, TArg3 arg3);

Now we can complete our lambda expressions:

Func<int, int> f1;

f1 = x => x * 2;

Func<int, int, int> f2;

f2 = (x, y) => x * 10 + y;

Func<int, int, int, int> f3;

f3 = (x, y, z) => (1 / x + 10) * y + z;

// A lambda expression with no arguments

Func<int> f4 = ()=> 10;

It is possible to use f1, f2 and f3 like any other delegate instances:

int r1 = f1(10);

int r2 = f2(5, 10);

int r3 = f3(13, 2, 3);

A lambda expression is transformed into an instance of a delegate pointing at a method. The method is auto generated at compile time with its body being the same as the body of the original lambda expression. For example:

Func<int, int> f1 = x => x * 2;

is transformed to the following:

Func<int, int> f1 = delegate(int x)

{

return x * 2;

};

The following points are taken directly from C# 3.0 Specification:

- Lambda expressions permit parameter types to be omitted and inferred whereas anonymous methods require parameter types to be explicitly stated.

- The body of a lambda expression can be an expression or a statement block whereas the body of an anonymous method can only be a statement block.

- Lambda expressions with an expression body can be converted to expression trees

- The parameters of a lambda expression can be explicitly typed:

(int x) => x * 2;

One last topic to introduce here is the notion of closure: Local variables can be used inside the body of lambda expressions. The behaviour here is very similar to how closure works in anonymous methods:

double y = 0;

Func<double, double> t = x => x * y;

double r1 = t(10);

y = 10;

double r2 = t(10);

After executing the above code, r1 is 0 and r2 is 100.

Lazy evaluation in C#

pedramr — Sat, 02 Jun 2007 20:37:00 GMT

What is lazy evaluation? If you ask a functional programming enthusiast, you will probably get a reply similar to the one below:

“Oh well, allow me to enlighten you:

- In lazy evaluation, computation terminates whenever any reduction order terminates.

- It requires no more steps than eager evaluation.”

An English translation of the above would probably be similar to this: we will only execute code when needed and only as many times as required regardless of where in the execution pipeline the code sits.

This is easily demonstrable using the notation of a functional programming language such as Haskell. Consider the following script which defines 2 functions:

Four :: Integer -> Integer
Four x = 4

Infinity :: Integer
Infinity = 1 + Infinity

The first function above simply returns the integer 4 for any x. The second function is a recursive function (It never terminates when used in an eager evaluation mode). In the world of C#, these functions would look similar to the ones below:

static int Four(int x)

{

return 4;

}

static int Infinity()

{

return Infinity() + 1;

}

Imagine the following pipeline of function calls (for simplicity, I will not use the Haskell syntax in here)

int x = Four(Infinity());

In eager evaluation – CLR’s default behaviour – the above will throw a StackOverflowException exception due to the never ending recursive nature of the Infinity method.

There are 2 different evaluation orders for the above listing. The one on the left never terminates but the one of the right terminates after the first iteration:

Eager (used by CLR)	Lazy
Four(Infinity()) // definition of Infinity => Four(Infinity() + 1) // definition of Infinity => Four(Infinity() + 1 + 1) => ...	Four(Infinity()) // definition of Four => 4

As you can see, lazy evaluation has some useful implications for program design. Many expressions can be thought of as pipelines therefore intermediate data structures need not exist all at once.

Let’s assume that we need to write a function which returns a list of all prime numbers:

static int GetPrimes()

{

List<int> primes = new List<int>();

int i = 1;

while (true)

{

if (IsPrime(i)) primes.Add(i);

i++;

}

Unfortunately, the list of prime numbers is an infinite list therefore it cannot be returned all at once. Ignoring the Int32.MaxValue limit, the code above will never cease executing.

In .NET 1.0, we introduced the notion of enumerators which allowed us to somewhat create demand-driven (lazy) execution. With enumerators, the next value that is required from the list is retrieved (and possibly calculated) only when the MoveNext() method is called on the enumerator.

In C# 2.0 we introduced the yield keyword to make the programmer’s life easier by automatically creating the helper IEnumerable and IEnumrator implementer class at compile time:

static IEnumerable<int> GetPrimes()

{

int i = 1;

while (true)

{

if (IsPrime(i))

{

yield return i;

}

i++;

}

The key point to notice with the above listing is that when GetPrimes() is called, this method does not calculate the first prime number until an enumerator is created from the returned object and the MoveNext is called on it. When MoveNext is called, then the first prime number is found and is accessible through the Current property of the enumerator. No other prime number is calculated until MoveNext is called again:

IEnumerable<int> ep = GetPrimes();

IEnumerator<int> enump = ep.GetEnumerator();

// claculate the first prime number
enump.MoveNext();
Console.WriteLine(enump.Current);

// claculate the second prime number
enump.MoveNext();

Console.WriteLine(enump.Current);

Result:

With the use of the yield keyword, we turned a never terminating method into a demand-driven function.

In C# 3.0 with the introduction of query expressions as part of the LINQ framework, we now see the real benefit of this amazingly useful compiler trick (yield keyword results in a code transformation at compile time). Assume the following query expression:

var q =

from c in customers

where c.City == "London"

select c.Name;

At compile time, it is compiled into IL with the following semantic:

IEnumerable<string> q =

customers

.Where(CustomersInLondon)

.Select(c => c.Name);

...

static bool CustomersInLondon(Customer c)

{

return c.City == "London";

}

As you can see both Where and Select methods also return an instance of a type implementing IEnumerable<string> meaning that they are not executed until an enumerator is created for q and its MoveNext method is called. Indeed CustomersInLondon is executed only when MoveNext is executing.

IEnumerator<string> e = q.GetEnumerator();

e.MoveNext();

Console.WriteLine(e.Current);

As mentioned earlier, a great benefit of lazy evaluation is that intermediate data structures need not exist all at once. In the above example, we don’t need to have the list of all customers in memory if we are only interested in the first 2 customers who live in London.

Extension methods in C# 3.0

pedramr — Sat, 02 Jun 2007 17:10:00 GMT

You can think of extension methods as the ability to add instance methods to already existing types. Having said that, I would immediately also tell you that it is just an illusion. You are not actually adding a method to an existing type. It is just a little trick that the compiler plays on you!

Let’s pretend that we want to write a simple static method which takes a collection of numbers and returns the average value of those numbers (for my functional programming fans, it should probably be implemented using a foldl).

This aggregate method would look something like this:

namespace CoolExtensions

{

public static class Extensions

{

public static double Average(IEnumerable<double> doubles)

{

double result = 0;

int counter = 0;

foreach (int d in doubles)

{

result += d;

counter++;

}

return result / counter;

}

If I want to make this into an extension method – a method that extends IEnumerable<double> - I can just use the this modifier on the first argument of the method.

public static double Average(this IEnumerable<double> doubles) { ...

Using the this modifier turns this static method into an extension method on any type which implements the IEnumerable<double> interface. If the namespace in which this extension method is defined is in scope (using CoolExtensions;), this method can be called as an instance method on any type that implements that interface. For example:

double[] doubles = new double[] { 1, 2, 3 };

// both statements below are semantically equivalent

double avg = Extensions.Average(doubles);

double avg = doubles.Average(); // extension method as an instance method

The above extension method works because doubles is of type double[] which implements the IEnumerable<double>. You also notice that when the method is used as an extension method, it loses the first argument. Visual Studio codename Orcas has IntelliSense enabled for extension methods with a different icon to regular instance methods:

Here are some more examples of extension methods:

public static class Extensions

{

static TResult M1(this TSource source) ...

static TResult M2(this TSource source, TArg0 arg0) ...

static TResult M2(this TSource source, TArg0 arg0, TArg1 arg1) ..

static TResult M4<T>(this TSource source, TArg0 arg0) ...

And here is how they can be called:

Extensions.M1(source);

source.M1(); // extension method as an instance method

Extensions.M2(source, arg0);

source.M2(arg0); // extension method as an instance method

Extensions.M3(source, arg0, arg1);

source.M3(arg0, arg1); // extension method as an instance method

Extensions.M4<T>(source, arg0);

source.M2<T>(arg0); // extension method as an instance method

As you can see, an extension method can still be called like an ordinary static method.

Some random but important points regarding extension methods from the C# 3.0 Specification:

- Extension methods can only be declared in static, non-generic and non-nested classes.

- The first parameter of an extension method can only have the this modifier (no other modifiers are allowed) and the parameter type cannot be a pointer type.

- An extension method becomes available in a namespace as long as it is declared in a static class within the namespace or is imported through the using namespace directive.

- Extension methods have lower precedence than regular instance methods on a type.

The way that the lookup of an instance method call is handled at compile time is similar to how it worked in C# 2.0 but with an additional lookup phase for extension methods. In order to illustrate this additional lookup phase, assume the following extension method which calculates the sum of a sequence of integers:

public static class Extensions

{

public static int Sum(this IEnumerable<int> ints)

{

int sum = 0;

foreach (int i in ints) sum += i;

return sum;

}

This method can now simply be used as an instance method on instances of types that implement the IEnumerable<int> interface:

int[] ints = new int[] { 1, 2, 3 };

ints.Sum();

In this example, the compiler will look at the type of int[] and attempts to find an instance method called Sum with no parameters. If such a method is found then the lookup is complete. However, if this method is not found, an extra lookup phase is performed. This time, the compiler will transform the signature of the method in the following manner:

IEnumerable<int>.Sum() è XXX.Sum(IEnumerable<int> ints)

The new signature is then used to find an extension method in static classes that are in scope.

Extension methods are less discoverable and more limited in functionality. In some scenarios they may also decrease the readability of your code. For these reasons, it is recommended to use extension methods sparingly and only in cases where instance methods are not feasible. To illustrate this point, assume the following extension method on all types (an extension method on the object type):

public static void Print(this object obj)

{

Console.WriteLine(obj.ToString());

}

With this method, you can now use the Print instance method on any type including value types:

123.Print();

12.8976.Print();

"string".Print();

Although this can be fun, it is not hard to see why it might not be the best solution.

Extension methods are often used in the context of query expressions which is another new feature in C# 3.0:

double[] doubles = new double[] { 1, 2, 3 };
var q =
    from d in doubles
    where d > 2
    select d;

The above query expression is semantically identical to the following method calls on the source (doubles):

var q =

doubles

.Where(d => d > 2)

.Select(d => d);

Both Where and Select could be instance or extension methods on the type of the source.

It is needless to say that you cannot use reflection to discover an extension method as an instance method. The listing below returns null for mi:

IEnumerable<int> ints = new int[] { 1, 2, 3 };

int p = ints.Sum();

MethodInfo mi = ints.GetType().GetMethod("Sum");

Local variable type inference in C# 3.0

pedramr — Thu, 31 May 2007 21:29:00 GMT

In C# 1.0 type declaration was very simple:

- Specify the type name (if an array then append [] to the end of the type)

- Follow by a local variable name

Here are some examples of this:

int i = 23;

double[] ds = new double[] { 1.0, 2.0 };

In C# 2.0 with the introduction of generics, it got slightly more complex. We can now compose new types and they look rather elaborative, and certainly not concise:

Dictionary<int, Queue<string>> dic =
new Dictionary<int, Queue<string>>();

Look closer at the above dictionary creation. You’ll soon notice that the type is repeated at both sides of the assignment and poses the logical question: Couldn’t we infer the type of the local variable (dic) automatically from the right hand side? Well, the answer to that is yes! Indeed, the type of the local variable could have been inferred at compile time by the compiler.

In C# 3.0 there is a new feature called “Implicitly typed local variables” which allows the type of a local variable being declared to be inferred from the expression which is used to initialise the variable. The var keyword is used as the type name for the variable.

There are a couple of initial points to mention in here:

- No variable called var should be in scope

- For backward compatibility reason, if there is a type called var then a variable of this type is declared

Let’s see some examples for this:

int i = 23;

double[] ds = new double[] { 1.0, 2.0 };

Dictionary<int, Queue<string>> dic =
new Dictionary<int, Queue<string>>();

The code above is precisely equivalent to the following implicitly typed declarations:

var i = 23;

var ds = new double[] { 1.0, 2.0 };

var dic = new Dictionary<int, Queue<string>>();

The second listing is more concise meaning that there is less code to achieve the same functionality as the first listing.

When dealing with type inference, the var keyword might be mistaken for the var keyword in languages such as JavaScript in which var means a variant type. The way var should be read in C# is “The type of the right hand side”. It is certainly not equivalent to a variant in JavaScript or VB6. In fact, we don’t have variant types in .NET and everything is strongly typed. It is also worth mentioning that using the var keyword is not the same as using the object type in .NET.

The C# 3.0 specification points out the following restrictions on the declarator in an implicitly typed local variable declaration:

- The declarator must include an initialiser (var i = 23;)

- The initialiser must be an expression and cannot be the null type at compile time
(Error: var x = null;)

- The local variable declaration cannot include multiple declarators

- The initialiser cannot refer to the declared variable itself
(Error: var x = x++;)

Where else except for local variable declaration can I use the var keyword?

- For declaring the variable used in the initialiser of a for loop

- Inside a using statement

- For the iteration variable of a foreach

Type inference is certainly a nicety to have however when used with anonymous types, it becomes a necessity (‘Anonymous types’ is yet another new feature of C# 3.0):

Customer c = GetCustomer();

var d = new { Name = c.Name, City = c.City };
Creation and initialisation of an anonymous type

An anonymous type is created automatically by the compiler at compile time. At design time we do not know the name of the type (hence the word “Anonymous”). So without the var keyword, it is probably impossible to declare a local variable that can hold an instance of the anonymous type.

Here is an example of type inference in a foreach:

string[] strs = new string[] { "hi", "bye" };
//s is inferred by the compiler to be string
foreach (var s in strs)
{
s.XXX(); // IntelliSense here will treat s as string
}

Non-CLS Exceptions

pedramr — Sun, 07 Jan 2007 16:56:00 GMT

Many developers are not aware that according to CLR it is perfectly OK to throw exceptions which are NOT derived from System.Exception: Exceptions such as DateTime, Int64 and String. Although languages such as C# do not allows programmers to throw these types of exceptions it should still be possible to catch non-CLS compliant exceptions using a catch block.

Pre to CLR version 2.0, the only way to catch non-CLS compliant exceptions was to introduce a catch block with no Exception section:

try

{

// Some code here which might

// throw non-CLS compilant exception

}

catch (Exception ex)

{

// Here we will be catching any

// CLS compliant type of exceptions

}

catch

{

// Here we will be catching any

// non-CLS compliant exceptions...

// Note that, this block on its own

// is capable of catching both compliant

// and non-compinat exceptions

}

In version 2.0 of CLR, any non-CLS compliant exception is automatically wrapped up by System.Runtime.CompilerServices.RuntimeWrappedException class which inherits from the Exception class. This class has a property which is set to the actual object which was thrown.

It is still possible to tell CLR not to wrap up the non-CLS compliant exceptions with the RuntimeWrappedException class. This is done using an attribute which affects the whole assembly:

[assembly: RuntimeCompatibility(WrapNonExceptionThrows = false)]