Think In Geek » c#

C#, the “and” operators and lazy evaluation

brafales — Mon, 12 Oct 2009 15:00:11 +0000

Today at work we found a bug. My workmate, not used to C#, usually uses the & operator to compare boolean values. However, in C#, the & operator does not use lazy evaluation.

One curious thing about C# is that it can use two different operators to calculate an and expression: the & operator and the && operator. The difference between both is that the first one (&) can be used both with integer types and boolean types. When used with integer types it will perform a bitwise comparison between the two, and when used with boolean values it will use the logical and operation between the two boolean values, evaluating all the parts of the expression. This means that using a code like this one:

if (someObject != null & someObject.SomeProperty == someValue)

will throw a runtime error if someObject is null, because it will try to obtain the SomeProperty value.

However, the && operator is only available to boolean expressions, and it uses lazy evaluation, this is, if the first condition evaluated is false, it will calculate false without evaluating the rest of the expression, because an and is only true if all the expressions are true.

Conclusion, be sure to always use &amp& when evaluating boolean values if you want to avoid run time surprises .

Creating and testing a Linked List based Queue in C# using Nunit

brafales — Thu, 09 Jul 2009 16:23:22 +0000

The Queue class (and Stack too) of the .NET Framework from Microsoft is implemented using an array. While this is a perfectly good approach, I think that a Linked List based implementation could be desired in some situations (specifically when the size of the queue is not fixed).

Since the implementation alone would be rather simple for a post, I’ll show you how to implement Unit Testing with the class using Nunit. Although this is a rather simple class to test I think it will show the basic concepts behind unit testing.

First of all let’s begin with the interface of the class. We will call it LinkedListQueue. We basically need the typical operations of a queue.

The interface (without the implementation) is going to be something similar to this:

using System;
public class LinkedListQueue
{
 
    #region LinkedListQueue Members
 
    public T Dequeue()
    {
        throw new System.NotImplementedException();
    }
 
    public void Enqueue(T item)
    {
        throw new System.NotImplementedException();
    }
 
    public T Peek()
    {
        throw new System.NotImplementedException();
    }
 
    public void Clear()
    {
        throw new System.NotImplementedException();
    }
 
    public int Count
    {
        get { throw new System.NotImplementedException(); }
    }
 
    #endregion
}

The thing about unit testing is to first write the different tests so we know what we want to test and then we have to write the code so the tests are passed. Following this convention, now is the time to write some tests using Nunit. To do so, we have to create a new project of type Class Library in Visual Studio (we could have the tests on the same code but it’s better to have it separately so we don’t bloat the real production code). For more information about how to install and set up Nunit I suggest you visit the site for more information. I called the project LinkedListQueueTest

Once we have the code, we can start writing tests in a special class which will have this modifier:

[TestFixture]
public class LinkedListQueueTest
{}

Inside this class we have to write one method for each test we want to perform. It’s usually a good practice to have one test per method on the class you’re testing. In our case, we will begin testing the Enqueue method. To mark a method as a test, we have to add a modifier to it like this:

[Test]
public void Dequeue()
{}

And in the body of the method, we have to perform the test we need. Usually the tests have a structure: creating an object on which to test, executing the method, and confirm that the result is the same as we expected. Let’s do a simple code for our test:

[Test]
public void Dequeue()
{
    LinkedListQueue queue = new LinkedListQueue();
    //We enqueue some items to test
    queue.Enqueue(1);
    queue.Enqueue(2);
    queue.Enqueue(3);
    queue.Enqueue(4);
    queue.Enqueue(5);
    //For each number enqueued we check that is removed properly and in the
    //queue order (FIFO)
    Assert.AreEqual(queue.Dequeue(), 1);
    Assert.AreEqual(queue.Count, 4);
    Assert.AreEqual(queue.Dequeue(), 2);
    Assert.AreEqual(queue.Count, 3);
    Assert.AreEqual(queue.Dequeue(), 3);
    Assert.AreEqual(queue.Count, 2);
    Assert.AreEqual(queue.Dequeue(), 4);
    Assert.AreEqual(queue.Count, 1);
    Assert.AreEqual(queue.Dequeue(), 5);
    Assert.AreEqual(queue.Count, 0);
    Assert.Throws(
        delegate
        {
            queue.Dequeue();
        }
    );
}

I suggest you read the Nunit documentation to see the different assertions you have available.

Now that we wrote our first test, we should start thinking and writing the rest of the tests. To simplify the post, here’s a full class showing some tests that you may have wanted to perform:

using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;
 
namespace ThinkInGeek.Collections.Generic.Testing
{
    [TestFixture]
    public class LinkedListQueueTest
    {
        [Test]
        public void Dequeue()
        {
            LinkedListQueue queue = new LinkedListQueue();
            //We enqueue some items to test
            queue.Enqueue(1);
            queue.Enqueue(2);
            queue.Enqueue(3);
            queue.Enqueue(4);
            queue.Enqueue(5);
            //For each number enqueued we check that is removed properly and in the
            //queue order (FIFO)
            Assert.AreEqual(queue.Dequeue(), 1);
            Assert.AreEqual(queue.Count, 4);
            Assert.AreEqual(queue.Dequeue(), 2);
            Assert.AreEqual(queue.Count, 3);
            Assert.AreEqual(queue.Dequeue(), 3);
            Assert.AreEqual(queue.Count, 2);
            Assert.AreEqual(queue.Dequeue(), 4);
            Assert.AreEqual(queue.Count, 1);
            Assert.AreEqual(queue.Dequeue(), 5);
            Assert.AreEqual(queue.Count, 0);
            Assert.Throws(
                delegate
                {
                    queue.Dequeue();
                }
            );
        }
 
        [Test]
        public void Enqueue()
        {
            LinkedListQueue queue = new LinkedListQueue();
            //We enqueue some items to test and check that the items are inserted correctly
            queue.Enqueue(1);
            Assert.AreEqual(queue.Count, 1);
            queue.Enqueue(2);
            Assert.AreEqual(queue.Count, 2);
            queue.Enqueue(3);
            Assert.AreEqual(queue.Count, 3);
            queue.Enqueue(4);
            Assert.AreEqual(queue.Count, 4);
            queue.Enqueue(5);
            Assert.AreEqual(queue.Count, 5);
        }
 
        [Test]
        public void Peek()
        {
            LinkedListQueue queue = new LinkedListQueue();
            //We enqueue some items to test
            queue.Enqueue(1);
            queue.Enqueue(2);
            queue.Enqueue(3);
            queue.Enqueue(4);
            queue.Enqueue(5);
            //We check that after a peeking we have the correct value but the item
            //is not deleted
            Assert.AreEqual(queue.Peek(), 1);
            Assert.AreEqual(queue.Count, 5);
            queue.Dequeue();
            Assert.AreEqual(queue.Peek(), 2);
            Assert.AreEqual(queue.Count, 4);
            queue.Dequeue();
            Assert.AreEqual(queue.Peek(), 3);
            Assert.AreEqual(queue.Count, 3);
            queue.Dequeue();
            Assert.AreEqual(queue.Peek(), 4);
            Assert.AreEqual(queue.Count, 2);
            queue.Dequeue();
            Assert.AreEqual(queue.Peek(), 5);
            Assert.AreEqual(queue.Count, 1);
            queue.Dequeue();
            Assert.Throws(
                delegate
                {
                    queue.Peek();
                }
            );
        }
 
        [Test]
        public void Clear()
        {
            LinkedListQueue queue = new LinkedListQueue();
            queue.Enqueue(1);
            queue.Enqueue(2);
            queue.Enqueue(3);
            queue.Enqueue(4);
            queue.Enqueue(5);
            queue.Clear();
            Assert.AreEqual(queue.Count, 0);
        }
    }
}

To see how our test behave, we have to open the resulting LinkedListQueueTest.dll in the Nunit tester program. As we have written no real code on the queue class, it’s obvious that our tests will fail. So let’s get our hands dirty and start programming our queue.

I will not go into the details because a linked list based queue is really easy to implement, so here’s the final code of the class:

using System;
 
namespace ThinkInGeek.Collections.Generic
{
    public class LinkedListQueue
    {
        #region Node inner class
 
        public class Node
        {
            public K Element { get; set; }
            public Node NextElement { get; set; }
        }
 
        #endregion
 
        #region Private members
 
        private int m_count = 0;
        private Node m_head = null;
        private Node m_tail = null;
 
        #endregion
 
        public T Dequeue()
        {
            if (m_head == null)
            {
                throw new InvalidOperationException();
            }
            //We have to return the item on the head and update the new head
            T currentItem = m_head.Element;
            m_head = m_head.NextElement;
            m_count--;
            return currentItem;
        }
 
        public void Enqueue(T item)
        {
            //We need to add the item and update the tail
            Node newNode = new Node();
            newNode.Element = item;
            if (m_tail != null)
            {
                m_tail.NextElement = newNode;
            }
            m_tail = newNode;
            if (m_head == null)
            {
                m_head = newNode;
            }
            m_count++;
        }
 
        public T Peek()
        {
            if (m_head == null)
            {
                throw new InvalidOperationException();
            }
            return m_head.Element;
        }
 
        public void Clear()
        {
            m_head = null;
            m_tail = null;
            m_count = 0;
        }
 
        public int Count
        {
            get { return m_count; }
        }
    }
}

The advantage of unit testing is that now the testing is going to be done automatically. The only thing we have to do is open the testing dll file into Nunit and see how’s the outcome. As we’re really good programmers, using the code I showed you, all the tests will pass

Unit Testing results window

This is a really simple example of how things should be done with unit testing using C# and Nunit, but I hope it can get you started and you can grasp the philosophy of it. For more information I really recommend reading the book Pragmatic Unit Testing in C# with NUnit.

Using IronPython to extend your .NET applications

brafales — Wed, 11 Mar 2009 15:44:32 +0000

One of the interesting new things on the .NET platform is the recent addition of Python and Ruby to the CLR. Both versions for .NET are called IronPython and IronRuby respectively, and they provide some new and good things to the platform.

Python and Ruby lovers will see now that they can use all the library and features of the .NET platform programming in their favorite scripting language. Since both of them are object oriented, you can now write fully fledged apps using either of them.

However, there’s another interesting application for IronPython and IronRuby: adding scripting support for your existing .NET applications. This can be a very useful and powerful way to extend your applications and give the user freedom to program their own mini programs, scripts or whatever in your applications. It could be good for defining rules, assigning and calculating values, etc.

I’ll provide a simple class you can use to add scripting to your application. I’ll use IronPython in this example.

First of all, you have to download IronPython and install it, and add the references to the assemblies on your project references.

The usual way to proceed in those cases is to provide the user of some local variables you give them access to, execute the script, and then recover the values of those or new variables. To do so, You can use a class similar to this one:

using System;
using System.Collections.Generic;
using System.Text;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
using Microsoft.Scripting;
 
namespace Scripting
{
	internal class PythonEngine
	{
        ScriptEngine m_engine;
        ExceptionOperations m_exceptionOperations;
        SortedDictionary<string, object> m_inputVariables;
        string m_script;
 
        internal PythonEngine()
        {
            m_engine = Python.CreateEngine();
            m_exceptionOperations = m_engine.GetService<ExceptionOperations>();
        }
 
        internal SortedDictionary<string, object> ScriptVariables
        {
            set { m_inputVariables = value; }
        }
 
        internal string Script
        {
            set { m_script = value; }
        }
 
        internal ExceptionOperations ExceptionOperations
        {
            get { return m_exceptionOperations; }
        }
 
        internal SortedDictionary<string, object> Execute()
        {
            //Create structures
            SourceCodeKind sc = SourceCodeKind.Statements;
            ScriptSource source = m_engine.CreateScriptSourceFromString(m_script, sc);
            ScriptScope scope = m_engine.CreateScope();
            //Fill input variables
            foreach (KeyValuePair<string, object> variable in m_inputVariables)
            {
                scope.SetVariable(variable.Key, variable.Value);
            }
            SortedDictionary<string, object> outputVariables = new SortedDictionary<string, object>();
            //Execute the script
            try
            {
                source.Execute(scope);
                //Recover variables
                foreach (string variable in scope.GetVariableNames())
                {
                    outputVariables.Add(variable, scope.GetVariable(variable));
                }
            }
            catch (Exception e)
            {
                string error = m_exceptionOperations.FormatException(e);
                //Do something with the pretty printed error
                throw;
            }
            return outputVariables;
        }
	}
}

Usage of this class is pretty simple. You have to provide the object the script you want to execute and the input variables the script will have available as local variables. Once this is done, you have to call the Execute method, and this method will either return the output variables of the execution of the resulting script, or throw an exception.

Full view of ComboBox drop-down list components in C# 3.0

alopez — Tue, 18 Nov 2008 12:43:02 +0000

By default in C# 3.0 ComboBox controls don’t provide support for showing drop-down list items if they exceed the width of their parent ComboBox, like this one:

Cropped ComboBox

This is annoying because users cannot read properly the information. To solve that problem, all we have to do is derive the ComboBox class and override the DropDown event as follows:

public class ComboBoxEx : ComboBox
{
	public ComboBoxEx()
		: base()
	{
		DropDown += new EventHandler(event_DropDown);
	}
 
	void event_DropDown(object sender, EventArgs e)
	{
		try
		{
			ComboBox comboBox = (ComboBox)sender; // Catch the combo firing this event
			int width = comboBox.Width; // Current width for ComboBox
			Graphics g = comboBox.CreateGraphics(); // Get graphics for ComboBox
			Font font = comboBox.Font; // Doesn't change original font
 
			//checks if a scrollbar will be displayed.
			int vertScrollBarWidth;
			if (comboBox.Items.Count > comboBox.MaxDropDownItems)
			}
				//If yes, then get its width to adjust the size of the drop down list.
				vertScrollBarWidth = SystemInformation.VerticalScrollBarWidth;
			}
			else
			{
				//Otherwise set to 0
				vertScrollBarWidth = 0;
			}
			//Loop through list items and check size of each items.
			//set the width of the drop down list to the width of the largest item.
			int newWidth;
			foreach (string s in comboBox.Items)
			{
				if (s != null)
				{
					newWidth = (int)g.MeasureString(s.Trim(), font).Width + vertScrollBarWidth;
					if (width < newWidth)
						width = newWidth;
				}
			}
			// Finally, adjust the new width
			comboBox.DropDownWidth = width;
		}
		catch {  }
	}   
}

The following picture shows the results of using the above control instead of the default one:

Non Cropped ComboBox

C# and the StringBuilder class

brafales — Wed, 16 Jul 2008 17:07:37 +0000

This morning I was working on a project at work. It’s a Web Application using the ASP .NET 2.0 framework and C# as a code behind language. My friend Ioannis came over to see what was I doing and when he saw I was appending some strings together he asked me this question: “are you using a StringBuilder to use those strings?“. And I replied with this answer: “no, I am not“. This kind of stupid dialog came over because last week we were discussing about using StringBuilders instead of the default String class operators to append strings each other in Java. It seemed using the StringBuilder class resulted in an overall performance gain. It was then when I asked: “don’t tell me this happens with C#, too?“. And he answered: “yes, it does!“.

So, what’s the matter with StringBuilders in C#?

It seems the same thing happens with Strings, C# and Java. Here is a copy paste from the MSDN web page about the StringBuilder usage:

The String object is immutable. Every time you use one of the methods in the System.String class, you create a new string object in memory, which requires a new allocation of space for that new object. In situations where you need to perform repeated modifications to a string, the overhead associated with creating a new String object can be costly. The System.Text.StringBuilder class can be used when you want to modify a string without creating a new object. For example, using the StringBuilder class can boost performance when concatenating many strings together in a loop.

So I decided to run some tests to see how much it was worth to change my code to use the StringBuilder class, because I use the string ‘+’ operator a lot in my program, and the results are simply amazing. Here you can find a chart comparing the times it took to concatenate a given number of strings using both methods. See for yourself and then… use StringBuilders from now on!

String usage

StringBuilder usage

Here’s the source code i used if you want to try it for yourself:

using System;
using System.Collections.Generic;
using System.Text;
 
using Adapdev.Diagnostics;
 
namespace SBuilder
{
    class Program
    {
        static void Main(string[] args)
        {
            HiPerfTimer timer = new HiPerfTimer();
            for (int i = 0; i < 100; i++)
            {
                StringBuilder sb = new StringBuilder();
                timer.Start();
                for (int j = 0; j < 1000 <strong> i; j++)
                {
                    sb.Append(j);
                }
                timer.Stop();
                double timeStringBuilder = timer.Duration;
 
                string s = string.Empty;
                timer.Start();
                for (int j = 0; j < 1000 strong> i; j++)
                {
                    s += j;
                }
                timer.Stop();
                double timeString = timer.Duration;
 
                StringBuilder line = new StringBuilder();
                line.Append(1000 * i);
                line.Append(";");
                line.Append(timeStringBuilder);
                line.Append(";");
                line.Append(timeString);
                System.Console.WriteLine(line.ToString());
            }
        }
    }
}

You can download the external timer classes from The Code Project.

The Double Check Design Pattern

brafales — Sun, 29 Jul 2007 17:21:37 +0000

One of the deficiencies of actual programming languages, specially those ones still widely used that are old, such as C or C++, is that they were designed having in mind the sequential programming paradigm. This usually means that those languages don’t have standard ways to work with multithreading features, and you usually have to rely on third party libraries to develop thread safe software.

Today I’ll be discussing a design pattern called Double Check, which can be widely used to manage the resource access, elimination and initialization in a safe thread way.

Consider another common design pattern: the Singleton Pattern. A singleton is a special class which is allowed to have one and only one instance in a program. This pattern can be used in a variety of ways, one of the most usual one is to store global program information, which, as its name states, is global and unique to the application, so having more than one instance of that class would have the burden to mantain them synchronized, or even more nasty consequences.

There are different ways to implement a singleton class. I will focus on C#, but the example shown here could be easily extended to other languages such as C++ or Java. The trick on the pattern consists on declaring the class constructor private. This way we can be sure no one will be creating new instances of that class at will. After having done this, we have to provide a public method, which usually has the name getInstance, that will be the one actually creating this item and returning it to the caller.

The code would look similar to this one:

public sealed class Singleton
{
    private static Singleton instance = null;
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
                instance = new Singleton();
            return instance;
        }
    }
}

Another way to create this singleton class would be doing the instantiation of the private variable on the class itself and not on the getInstance method, but this second way gives us a lazy initialization, so the variable is actually instantiated only when it’s needed, and never before (who knows, maybe we will never need it in some circumstances).

This implementation is perfect… as long as this method isn’t called twice (or more) at the same time. Consider what would happen if two threads requested an instance of the singleton class: both threads would check for the instance being null, and both threads would create the instance. That would sure lead to an unknown behaviour, and more than one instance of the class would be in the program, which is exactly what we wanted to avoid.

The first solution that comes in mind is to lock the method so multiple threads must wait to enter the method and get the singleton instance. It would look like this:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            lock(semaphore);
            if (instance == null)
                instance = new Singleton();
            return instance;
        }
    }
}

This way we ensure that if n threads try to access the routine at the same time, only one will be initializing the singleton instance, since when the others gain the access to the method again, that instance won’t be null anymore. However, even if this solution is valid and works, it has a serious performance problem. Consider the situation where the instance has been already created. Then more than one thread access the routine again to get that instance. What will happen is that those threads will have to block and wait for other threads to finish, even if the instance is not null, so in any case will be created again. Conclusion: we are blocking threads that don’t need to be blocked. “Ok, you may say, we will put the lock inside the if clause, and we’ll have the issue resolved“. Let’s take a look at this solution:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock(semaphore);
                instance = new Singleton();
            }
            return instance;
        }
    }
}

You don’t have to be a genious to see that this is not working, either. It will work after the instance has been created, because the threads won’t be entering the if clause, and they won’t be blocked. But if we are in the same situation as the described in the first place –this is, more than one thread entering the method before the instance has been created–, we have the same problem we had before: the singleton will be created more than once.

The final solution is simple: check again for the variable being null! This is why this pattern is called Double Check. The final code would look like this one:

public sealed class Singleton
{
    private static Singleton instance = null;
    private static object sempahore = new Object();
 
    private Singleton(){}
 
    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock(semaphore);
                if (instance == null)
                    instance = new Singleton();
            }
            return instance;
        }
    }
}

This way, we allow the threads to pass by the if clause if the instance has been already instantiated, and if it has not, the threads will get blocked, and the first one to gain access to the method will do the instantiation. Further threads will check again against the instance being null or not, so it won’t be created again.

Altough this pattern may be implemented similarly in other languages, be aware that, as I said before, a lot of them were never intended to deal with multithreading, and that compiler optimizations may give you code which is not really thread safe, or that actually is not optimized. Here you have a link discussing this issue with Java and C++: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.