Collection initializers: adding multiple values
Collection initializer are a wonderful feature in C# 3.0. Instead of calling the Add method of the collection for each item that should be added to the collection it’s possible to add the items in curly brackets after the constructor call; the approach looks very similar to how to initialize arrays with a fixed set of values:
var list =
This code is unfolded by the C# compiler to something like this (not exactly like this but very similar):
var list =
// add the items to it.
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(5);
// …
This pattern works wonderful with a list that exposes an Add method that expects only one argument. But does this model also work with, for example a Dictionary<K, V>? The dictionary class has an Add method that expects two values: a key and a value.
The answer is yes; the scenario extends also to a dictionary. The code to initialize a dictionary with values looks very like the mathematical notation for a set holding sub sets:
var dictionary =
{
{ “Hello”, 1 },
{ “World”, 2 }
}
After having found out that this works I went curious and tried the notation (the embedded curly brackets) also with the list class:
The C# compiler doesn’t create any warning or error for this piece of code. It seems as if you can always put the items that are added to a list also into the curly brackets.
Now, this made even more curious and created a class that has an Add method that expects three arguments:
{
public void Add(int index, string key, string value)
{
// code to add the item to the list
}
}
To add items to the FooList I added the following code to the application:
var foo =
{
{ 1, “key1″, “value1″ },
{ 2, “key2″, “value2″ }
};
… and the unexpected happened: this piece of code didn’t compile. But it wasn’t the initialization that gave me a compiler error but it was the implementation of the FooList.
The C# compiler wanted me to implement the IEnumerable interface into the FooList; otherwise the collection initializer isn’t allowed. This makes sense because all lists (or collections for that matter) need to implement the interface and collection initalizer should only be available for data structures that are implemented to hold a set of items.
After adding the IEnumerable implementation the code looked something like this:
{
public void Add(int index, string key, string value)
{
// code to add the item to the list
}
#region IEnumerable<KeyValuePair<string, string>> Members
public IEnumerator<KeyValuePair<string, string>> GetEnumerator()
{
// code to implement the enumerator.
}
#endregion
#region IEnumerable Members
System.Collections.IEnumerator
System.Collections.IEnumerable.GetEnumerator()
{
return this.GetEnumerator();
}
#endregion
}
I like the collection initialization pattern very much. But more than that it is really cool that the C# team made them very flexible. This allows the developers to use it in a varity of scenarios and doesn’t limit it to the initialization of lists with just one value! Great job, great feature!
Published on Apr 29th, 2008 —
Tags: C#, C# 3.0, Compiler 
Comments (0) 
digg it!
kick it
Who listens where?
Ever needed a way to understand if an application is installed that listens to a certain port; and that in C#? Some people need such features. I don’t know why exactly but it could be useful to make sure that you don’t use a port that is already used by another application.
In C# there are two ways to understand if somebody already listens on a port: you could create a Socket and check for a SocketException (and there for a specific error code) to understand that something went wrong or you could use the IPGlobalProperties class.
I tend to like the second approach a lot more because exceptions shouldn’t be used to control the flow of an application and are also quite slow.
Now since we are in C# 3.0 we can spice the whole thing up by using a LINQ expression. The GetActiveTcpListeners method on the IPGlobalProperties class returns an array of all active TCP listeners. If you ever coded in C# 3.0 you will know that an array implements the IEnumerable interface and that we can use LINQ with all classes that implement that interface:
/// Returns whether the given port is open.
/// </summary>
/// <param name="port">The port that is checked for being open.</param>
/// <returns></returns>
public static bool IsPortOpen(int port)
{
// get all active listener and check if one of them has
// the given port.
var connection = (from c in IPGlobalProperties.GetIPGlobalProperties()
.GetActiveTcpListeners()
where c.Port == port
select c).FirstOrDefault();
// if we got null none has the open port.
return (connection != null);
}
Create Mixins with Interfaces and Extension Methods
Bill Wagner (a MVP) has written a interesting article on how to create mixins with interfaces and extension mehods in C# 3.0. The ideas can easily be extended to VB.NET:
Mixins are small utility classes that define some useful functionality that will usually become part of something larger. For example, a class that implements a serial number to uniquely identify an object, or a timestamp that reports when an object was created. In C++, these mixin classes would be created using regular class definitions, and larger classes that wanted to use the mixin behavior would simply inherit from the mixin, in addition to any base classes it needed. Because the .NET Framework does not support multiple inheritance, we’ve typically used interface to define mixins. That works, but it’s not as powerful. One of the limitations of using interfaces to define mixin behavior is that every class that implements an interface must reimplement every method defined in that interface. That leads many developers to creating minimal interface definitions. (IEqualityComparer<T> has one method, IComparable<T> has only method). In those instances, the interface’s full functionality is completely defined in those small methods. But, what about cases where your interface can, or should, contain many more methods in order to support the developers that want to use the interface? That’s a perfect use case for extension methods. By creating extension methods using the interface, you can inject many more methods into the public definition of the interface, without forcing every developer to re-create those methods whenever he or she implements that interface. [...]
Partial methods, automatic properties and the “var” keyword
This post will cover three additions to C# 3.0 that are: partial methods, automatic properties and the “var” keyword. All of them are quite useful but the first two really look like version 1.0 features. But one at a time:
Partial methods
Partial methods only work in partial classes. Partial classes consist always of two files where the two parts of the class are split up in two files (that’s not a must but most often true). During the compile process the compiler is then putting these two files together and generates one single class out of them.
An interesting scenario for partial classes is with tools (for example code generators); where one part of the class is generated by a tool and the other part is custom code that is created by the developer.
That’s also where partial methods come in handy. The tool creates the partial method stub (and invokes it also in some parts of its code) while generating its part of the partial class. The developer can then implement the partial method’s body if that is required. During compliation the C# compiler looks if the partial method has been implemented by the developer. If not all calls to the partial method and the partial method stub are removed, otherwise the stub is replaced by the implementation of the developer.
Partial methods have some limitations: they are always private and they need to return void. That might be very limiting but works great for notification services or similar features:
{
public static void Main()
{
// create an instance of the class
Foo f =
// and invoke the method.
f.PrintName();
}
}
// A partial class that holds methods.
public partial class Foo
{
// prints additional information to the screen.
// this is a partial method.
partial void PrintAdditionalInfo();
// prints the name to the screen.
public void PrintName()
{
// prints the name.
Console.WriteLine(“Hi Joe.”);
// invoke the partial method to print
// additional information.
PrintAdditionalInfo();
}
}
// The second part of the partial class.
public partial class Foo
{
// the implementation of the partial method.
partial void PrintAdditionalInfo()
{
Console.WriteLine(“I have been called!”);
}
}
Automatic properties
Have you ever created a property for the pure sake of databinding? In that case you had to create the class field and the property with a getter and setter method. With automatic properties most of that work is done for you, by the compiler (btw. try the “prop” snippet to be even faster when creating them):
{
// two automatic properties.
public int ID { get; set; }
public string Name { get; set; }
}
But automatic properties are very very limited. You can’t, for example, only define the getter or the the setter, which makes perfect sense because then there is no other way to set or fetch the value: you don’t have any information about the private field.
But you can’t even change the modifier of the getter or setter to private; or what is a lot more important: implement one of the two methods. It’s impossible to, for example, add validation code to the setter without also implementing the getter. If you want to do that you are back in C# 2.0 world where you have to implement everything on your own: there is no magic field that you can query to get the value that is currently stored in the field or that you can use to set the a value.
Automatic properties are only useful for prototyping and such. I can only see very limited usage in real-world code.
The “var” keyword; or anonymous variables
The var keyword is very useful. Actually it is the most useful addition of all the additions in this post. It allows you to omit the typing of the type of a variable and saves therefore time. As you might have noticed in my previous posts I like new features that save me time!
{
// create a new datetime variable.
var date = DateTime.Now;
// and an int variable.
var value = 1;
// and a string variable.
var text = “this is a text”;
// and a list.
var list =
// and an int array.
var array =
// store the result of a LINQ query.
var result = from f in list
where f > 3
return f;
}
There are also some limitations to the var keyword. It can’t be used outside of methods, for example, it can’t be used for the type of a class field.
It can’t also be used as the type of an argument of a method. That’s because the var keyword only removes the writing of the type: the compiler very clearly knows the type of the varaible (try to hover over the var keyword to see the actual type in the intellisense tooltip). If the var keyword would be allowed for the type of a method’s argument the type couldn’t be statically determined and that’s why it is not allowed. The var keyword is not adding dynamic typing to the C# language!
Published on Jan 30th, 2008 —
Tags: automatic properties, C# 3.0, partial methods Comments (2) digg it!
kick it
Member Initialization and Collection Initialization in C# 3.0
Member initialization and collection initialization are two new features that have been introduced with C# 3.0. I like both a lot because they are very handy and reduce a lot of typing. Even more they finally make initialization code look a lot better!
Collection Initialization
This feature is very useful and I think the best thing to introduce it is via an example - more exactly two examples: one in C# 2.0 (without the feature) and one in C# 3.0 (using the feature):
List<int> list1 =
list1.Add(1);
list1.Add(2);
list1.Add(3);
list1.Add(4);
// and with collection initialization (C# 3.0).
List<int> list2 =
You can see it saves us a lot of typing and it looks also better. But this type of initialization works only for data or variables that are already known before compile time. You can’t construct a list with a varying amount of items in this way. But that’s also not the goal of this feature. The syntax looks exactly like the one to initialize an array with a predefined set of data. Internally the compiler converts the given syntax to the calls that we had to type in C# 2.0 and earlier.
This feature works with all classes that implement the ICollection<T> interface.
Member Initialization
This feature allows us to initialize properties during construction of the instance. I will also introduce it with an example in C# 2.0 and C# 3.0 code:
Button button1 =
button1.Text = “This is a sample text.”;
button1.BackColor = Color.White;
button1.TextAlign = ContentAlignment.TopCenter;
// and with member initialization (C# 3.0).
Button button2 =
{
Text = “This is a sample Text”,
BackColor = Color.White,
TextAlign = ContentAlignment.TopCenter
};
This way of initializing the members saves us a lot of typing and reminds me a little bit of the VB.NET’s “With” keyword.
This feature is very useful if you work with controls. One characteristic of controls is that their constructor never takes any arguments. That allows you to place them on a form (or another control) without having to specify anything: the form’s designer just creates the control by calling the default constructor. All the control’s settings are then specified by modifying the properties. If you construct a form (may it be a Windows form or even a web form) in code this addition will save you a lot of time and typing.
Published on Jan 28th, 2008 —
Tags: C# 3.0, Collection initialization, Member initialization Comments (0) digg it!
kick it
Anonymous types in C# (and .NET 3.5)
So what the heck are anonymous types all about? What’s the difference between a normal type and an anonymous type? First and most important: the anonymous type has no type name. Actually that is not 100% true. The anonymous type has a type name (because all types in .NET need to have one) but it is the compiler who generates the name, not the developer itself and you won’t see it in your code.
Another important difference is that the (C#) compiler generates a type that can only be initialized once and no longer altered afterwards. The type instance is created and some values are assigned to it but later in the code they can’t be changed anymore. The anonymous type is a so called immutable type (= initialize once and never change it again; System.String is another prominent immutable type).
Most often you will find anonymous types as a result of a LINQ query:
{
static void Main(string[] args)
{
// create a list with dummy users.
// the user class has a Name and Age property.
List<User> users =
users.Add(
users.Add(
users.Add(
// query the items for user with an age above 14.
var result = from u in users
where u.Age >= 15
// put the result in a anonymous type
select
// loop over the result.
foreach (var item in result)
{
// print out the name of the item.
Console.WriteLine(item.Name);
}
}
}
This is also why anonymous types have been introduced. They allow us to create a type on the fly and therefore return only certain values of a given named (= non-anonymous) type. This is very handy when only a subset of properties is needed, properties are joined together or even objects are joined together.
But anonymous types can also be used in own code without expressing them in a LINQ expression. For example when variables should be aggregated together for a short period:
var anonymousType =
Age = age, Nationality = nationality };
// print the name to the console.
Console.WriteLine(anonymousType.Name);
This might not be found that often in real-life code because anonymous types are limited. They can, for example, not be passed to other methods - well it could be done but that would mean to pass them as System.Object and therefore their properties can only be accessed by using reflection.
var result = from u in users
join g in calls on u.ID equals g.UserID
// put the result in a anonymous type
select
CallName = g.Name, g.TimeStamp };
This is another example on what we can do with the anonymous types. In this case the LINQ query joins two objects (User and Call) together and as result the user’s name, the call’s name and time stamp are returned. To avoid problems (like the two objects expose the same properties), we can specify the property names of the anonymous type and assign the values to them (this is also done in the example). Even more, in the example, the user name is assigned as a concat of the first and the last name.
Another interesting question is on how the C# compiler exactly translates the code. The following screenshot shows the class that has been generated for the first anonymous type in this post:
The name is completely compiler generated and is also incremented for each new anonymous type in the program. For all the arguments (in our case one) that are passed to the anonymous type an argument in the constructor has been defined. What’s also important to know is that the GetHashCode() and Equals(Object) methods have been overriden. This has been done to allow LINQ to store the anonymous types instances in a dictionary and fetch them later on. This is also why the properties (in this case the Name property) and the internal fields are marked as read-only in the anonymous types. The GetHashCode() method relies on the content of the fields and if they are altered while being in the dictionary the instance can’t be find anymore later on.
Another interesting thing is that the C# compiler recycles anonymous types. This means if we have like two anonymous type’s instances where we specify the exact same properties we will end up with getting the exact same anonymous type:
var result = from u in users
select
// create an anonymous type instance with a name.
var anonymousType =
// prints TRUE to the console.
Console.WriteLine(anonymousType.GetType() == result.First().GetType());
But how to detect anonymous types in an application? Let’s say you have a framework and you want to understand whether a type is an anonymous type. The bad news first: there is no way to be 100% sure that a type is an anonymous type as the name is completely generated by the compiler and there is no flag that says that the given type is an anonymous type. But a heuristic can be implemented to detect at least the anonymous types that are generated by VB.NET and C#:
{
if (type == null)
throw
// HACK: The only way to detect anonymous types right now.
return Attribute.IsDefined(type,
&& type.IsGenericType && type.Name.Contains(“AnonymousType”)
&& (type.Name.StartsWith(“<>”) || type.Name.StartsWith(“VB$”))
&& (type.Attributes & TypeAttributes.NotPublic) == TypeAttributes.NotPublic;
}
Attetion: Keep in mind that this is a hack and might not work with future versions of the C# and VB.NET compilers.
What exactly are lambda expressions in C#?
Yesterday I watched a very interesting Channel 9 video with Erik Meijer and Charles Torre. The video is about functional programming and why that is important in the multi-core world. They talk also about LINQ and lambda expressions and by the end of the video Erik mentions that he often gets the question about what lambda expression exactly are (in C#). So what are they?
To understand that we should probably go a little bit back in time. Let’s go back to the time of .NET 1.0 (C# 1.0) and start with the concepts of delegates. Delegates are a concept that wasn’t completely new with the advent of .NET. It was there before and for example in C++ they were called “function pointer”, which is probably more clear about what they do: a delegate holds a reference to a function (or method; whatever you like more) and allows you to call that function later on in time.
In .NET they renamed the concept to “delegate” and added type-safety to it. That means you have to exactly specify in the delegate what result type you expect and how many arguments and of what type you expect. After that you can use your delegate to point it to a method that has the specified signature; if you try to point it to a method with another signature you will get a compiler error, which is good! You can then pass the method around as if it is a variable:
{
// Definition of the delegate.
public delegate void MyCoolDelegate(string arg);
static void Main(string[] args)
{
// create the delegate and point it to the "PrintToConsole" method.
MyCoolDelegate myCool =
// invoke the delegate.
myCool(“Test”);
}
public static void PrintToConsole(string value)
{
Console.WriteLine(value);
}
}
A delegate is just a reference to a method that you can use as if it is a variable. You can pass it to methods and invoke it whenever you think it is required. Delegates are a powerful concept because now not only variables are data, but also functions/methods can be threaten as if they are data. Functions have become first class citiziens.
Let’s fast forward little bit and stop at the time when .NET 2.0 and C# 2.0 were released. For C# 2.0 the C# team added something very nice and useful: anonymous delegates or better known as anonymous methods.
The difference between anonymous methods and traditional delegates (as in .NET 1.0) is only that you don’t need to define a method somewhere else and point to it with a delegate to do the job. You directly define the method where you would create the delegate and the C# compiler will take care of it. The C# compiler will create the method for you and convert it into something that looks exactly like in .NET 1.0.
Let’s compare the tranditional delegate and anonymous method ways:
internal sealed class Program
{
static void Main(string[] args)
{
// create a list with some data.
List<string> list =
list.Add(“value1″);
list.Add(“value2″);
// find in the list. We need to specify a method here
// that does the logic to find the data we need.
string result = list.Find(
}
// This method finds the data in the list.
static bool FindInList(string value)
{
return (value == “value2″);
}
}
// — the anonymous method
internal sealed class Program
{
static void Main(string[] args)
{
// create a list with some data.
List<string> list =
list.Add(“value1″);
list.Add(“value2″);
// find in the list by using an anonymous method.
string result = list.Find(delegate(string value)
{
return (value == “value2″);
});
}
}
You can clearly see the difference here. With the anonymous method we don’t need to create another method and a delegate that points to that method. We just say that we want to use a delegate here and specify the body of the method. It’s much more convenient to use an anonymous method instead of the traditional delegate way. The reason for that is that the code that belongs together stays together.
Another nice feature that has been introduced with anonymous methods is the possiblity to use variables that are defined outside of the method inside the method:
{
// create a list with some data.
List<string> list =
list.Add(“value1″);
list.Add(“value2″);
string toFind = “value2″;
// find in the list. We need to specify a method here
// that does the logic to find the data we need.
string result = list.Find(delegate(string value)
{
return (value == toFind);
});
}
In the example you can see that I use the “toFind” variable inside the delegate body although it is defined outside of it. That’s some magic that is done by the C# compiler: in this case the C# compiler doesn’t only create a method for us but a whole class (that contains the method) where the value that we use in the body is passed in as class member. That is why we can access the value inside of the method body: as class member it is part of the class and you have access to the class members from inside a method.
Now let’s move on to the present day and C# 3.0 (and .NET 3.5) and speak about lambda expressions. Lambda expression are just the next step in the “delegate evolution”. The compiler now even hides away the whole “delegate(…) { … }”. It’s is very convenient because that saves us a lot of typing!
A lambda expression always consists of a left and a right part. The left part is on the left side of the “=>” and the right part is on the right side of it. The left part holds the list of arguments, where we even don’t need to specify the types because they can be automatically fetched by the compiler. The right side contains the body of the method. A lambda expression always expects us to return some value that is why we can also omit the “return” keyword:
{
// create a list with some data.
List<string> list =
list.Add(“value1″);
list.Add(“value2″);
string toFind = “value2″;
// find in the list. We need to specify a method here
// that does the logic to find the data we need.
string result = list.Find(value => toFind == value);
}
To sum it up: lambda expressions are just delegates (or type-safe “function pointers”). They only look as they are because some assumptions are taken (like a lambda expression are functions and therefore always returns a value) and the types can be automatically fetched by the compiler. The nice side effect is that lambda expressions save us a lot of typing and time. 
Extension Methods in C# 3.0
I have created a short screencast that introduces you with extension methods in C# 3.0.
In this webcast I explain why extension methods have been added to .NET 3.5. What are the benefits of using them? Then I’m going to show you how to create your own extension methods in C#. I also explain how the extension method calls are translated by the compiler. In the end I also show the problems that might come up when extension methods are used heavily in applications.
Click here to watch the screencast
Published on Dec 29th, 2007 —
Tags: .NET, C# 3.0, extension methods, screencast Comments (1) digg it!
kick it