Kristof Verbiest - Bite-size C#

3D fractal experiments: Mandelbulb

2011-01-15T17:09:00.004+01:00

I am really fond of 3D graphics (as you can see from my previous posts). But I am also a big fan of fractals. Good news: with the invention of the Mandelbulb we can have them both combined! The Mandelbulb is a variation of the classic Mandelbrot fractal, but in 3D. Lately I've been experimenting with Mandelbulber, a free piece of software to create images and videos of Mandelbulbs (and other related 3D fractals).

Here is a short example of what I've come up with:

3D in Silverlight part 4: spherical image mapping

2010-12-31T16:05:00.002+01:00

Spherical image mapping is a technique to wrap a 2D image around a 3D sphere. In my little ray tracer, I apply this technique to create an earth-like object.

Screenshot:

The same technique is used to wrap the image around a cube which gives an interesting effect.

Live version:

[It might take some time until this Silverlight application is loaded so please be patient. If you're viewing this post in an RSS reader (such as Google Reader), you might have to open it in your browser.]

Happy 2011!

3D in Silverlight part 3: planar texture mapping

2010-12-24T11:38:00.005+01:00

A quick update before the holidays: the ray tracer now also supports planar texture mapping. This was actually very simple to implement, the most difficult part turned out to be to load the bitmap in memory. In the example below I've used a free texture that was downloaded here.

Screenshot:

Live version:

Happy holidays!

Silverlight: loading a WriteableBitmap from file

2010-12-24T09:51:00.003+01:00

I’ve just spent quite some time trying to do something that seems very simple: embedding an image in a Silverlight application and loading this image into a WriteableBitmap (because I need to read the values of the individual pixels).

My first attempt was to add the image to my project as a resource and use the following code:

Uri uri = new Uri("Images/Texture.jpg", UriKind.Relative);

BitmapImage imageSource = new BitmapImage(uri);

WriteableBitmap bitmap = new WriteableBitmap(imageSource);  // EXCEPTION

However, an exception is thrown on the last line. Luckily the internet came to the rescue, and these two great site suggest basically the same solution:

Using BitmapCreateOptions.None to make sure the bitmap begins to load immediately.
Subscribing to events to know when the image has actually loaded.

However the proposed solution did not work in my case because the image fails to load with an AG_E_NETWORK_ERROR error.

In the end I took a different approach: I load the resource using Application.GetResourceStream so I’m sure that the data is completely loaded before it is handed to the WriteableBitmap. This is the code:

StreamResourceInfo sri = Application.GetResourceStream(new Uri("Images/Texture.jpg", UriKind.Relative));

BitmapImage src = new BitmapImage();

src.SetSource(sri.Stream);

WriteableBitmap image = new WriteableBitmap(src);

In my case it has the advantage of being synchronous which makes the overall code much simpler (but I understand that asynchronous behavior may often be better in a web-context).

When adding your image to your Silverlight project, the build action should be set to ‘Content’ instead of ‘Resource’. This means that the image will not be included in the dll, but it will be stored in the xap-file. You can check this by renaming the xap-file to zip and looking at the content.

So there are some non-intuitive steps involved when trying to accomplish this simple task. Hopefully this post can be helpful if someone else has this problem.

3D in Silverlight part 2: the cube

2010-12-18T16:46:00.003+01:00

I’ve added support for cubes to my ray tracing code. This is a screenshot for those who do not whish to install the Silverlight plugin:

The code still runs at about 20 fps on my PC (which is just acceptable). You can check it out yourself:

[It might take some time until this Silverlight application is loaded so please be patient. If you’re viewing this post in an RSS reader (such as Google Reader), you might have to open it in your browser.]

Real-time ray tracing in Silverlight

2010-11-24T15:37:00.010+01:00

I’ve always been very interested in computer generated graphics. A technology that I find particularly interesting is ray tracing. This technique is based on the physical interaction between light and materials, and it can be used to generate very realistic images.

Because of the physical accuracy, this technique is very suited to predict how something will look before it’s even built. When we were in the process of building our home, I created several ray-traced images that we used to choose the color of the bricks, the windows, the roof, … This way it was possible to create virtual versions of our future home and select the one that most matched our taste. This is such a ray traced image that I created:

Developing a ray tracer is not very difficult and through the years I’ve written some simple ray tracers. Unfortunately the calculations are very CPU-intensive. That is the reason why 3D games use different techniques which are also nice to look at but they are not physically accurate. But computers are getting faster and faster, so real-time ray tracing will likely become feasible in the near future.

As a test-case, I’ve optimized my old ray-tracing code and I’ve managed to get it to run at real-time speed. Check out this Silverlight version:

Note that you need a fairly fast CPU to get it to run real-time (on my quad-core it runs at 20 frames per second). You don’t need a fancy graphics card because this ray tracer only uses the CPU. The implementation is fairly straightforward, no real tricks have been used to improve the performance (other than common sense). I believe that, given enough effort, it would be possible to improve the performance considerably. That would allow it to render a more complex scene real-time.

Oldskool demo effect in Silverlight: plasma

2010-11-21T10:17:00.002+01:00

Just like last week, I’ve tried to recreate a demo-effect in Silverlight. This time I chose the plasma-effect which was very popular (it can be seen for instance in the classic State of the Art demo).

Actually this effect is much easier to implement than the twister of last week. I’m not the first one to implement it in Silverlight: other versions can be found here and here. Example code can be found here and here (but I used another variant).

[I’ve noticed that it might take some time until the Silverlight application is loaded, so please be patient. If you’re reading this in an RSS reader (such as Google Reader) you will have to open this post in your browser to see the effect.]

Oldskool demo effect in Silverlight: the twister

2010-11-17T16:55:00.005+01:00

As a kid, I was really fond of those oldskool demos on the Commodore 64 and the Commodore Amiga (but of course back then they weren't called oldskool). For those of you who have no idea what I'm taking about, you can watch most of these demos on youtube these days (such as here). Remember that these were created on hardware that is really ancient compared to nowadays.

These demos are created by programmers and artists with only one purpose: to impress other programmers and artists. In many aspects they resemble magician's tricks: they seem very impressive on the surface but underneath they use all kinds of tricks to make this possible. For instance, many 3D effects in demos were not really 3D at all. The tricks involved were kept very secret, but if an effect was very impressive, many other demo programmers would try to replicate and improve it (as is the case with magician's tricks).

I've recreated one of these effects in Silverlight. As a bonus I've added anti-aliasing and soft shadows (which weren't common in the old days). In the tradition of the oldskool demos I won't say how this was done, but maybe you can figure it out?

Enjoy!

[If you're reading this post through an RSS reader (such as Google Reader), you might have to open the post in a separate window of your browser to see the effect.]

Saving and restoring GDI+ state

2008-12-05T16:18:00.001+01:00

When you create complex drawing code, you probably will split this over multiple methods and pass the Graphics-object between these methods. But because the Graphics-object contains state, all changes that you apply in a method will be propagated to the other methods as well. Often this is not what you want.

The common way to work around this is to reset all the changes that you made at the end of the method:

        1: void PaintBackGround(Graphics g)

       2: {

       3:     SmoothingMode oldSmoothingMode = g.SmoothingMode;

       4:     try

       5:     {

       6:         g.SmoothingMode = SmoothingMode.AntiAlias;

       7:         ...

       8:     }

       9:     finally

      10:     {

      11:         g.SmoothingMode = oldSmoothingMode;

      12:     }

      13: }

But if your code changes a lot of properties this will become cumbersome. In these cases it is simpler to save and restore the entire Graphics-state like this:

       1: void PaintBackGround(Graphics g)

       2: {

       3:     GraphicsState oldState = g.Save();

       4:     try

       5:     {

       6:         g.SmoothingMode = SmoothingMode.AntiAlias;

       7:         ...

       8:     }

       9:     finally

      10:     {

      11:         g.Restore(oldState);

      12:     }

      13: }

Creating a single-instance application

2008-11-26T13:08:00.001+01:00

A lot has been written on the internet on how to create a single-instance application in C#. The proposed implementations fall into three categories:

Check if a process with the same name is already running (using GetProcessesByName). This is plain wrong because it needs administrator privileges. Furthermore it will not work if there is another process that happens to have the same name as your process.
Using the Microsoft.VisualBasic namespace (as explained here). This probably works OK (I have never done this), but it feels a bit wrong. Note that this approach is promoted in the book ‘Windows Forms 2.0 Programming’.
Using a Mutex.

Personally I think that the last approach is best, but there are some details that you need to get correct if you want to rely on this. This is the pattern that I propose:

        1: static class Program

       2: {

       3:     static Mutex s_Mutex;

       4:  

       5:     /// <summary>

       6:     /// The main entry point for the application.

       7:     /// </summary>

       8:     [STAThread]

       9:     static void Main()

      10:     {

      11:         bool instantiated;

      12:         // WARNING: you need to replace the GUID in this string!

      13:         s_Mutex = new Mutex(false, "Local\\MyAppName{A6F214AB-669D-41B2-9F30-8DD5E5AC9AE1}", out instantiated);

      14:         if (!instantiated)

      15:         {

      16:             MessageBox.Show("The application is already running");

      17:             return;

      18:         }

      19:  

      20:         Application.EnableVisualStyles();

      21:         Application.SetCompatibleTextRenderingDefault(false);

      22:         Application.Run(new Form1());

      23:     }

      24: }

The pattern is applied to a Winforms application, but of course it can be applied to any type of application.

For those who don’t know what a mutex is: it is a Windows kernel-object that can be used for synchronization between threads and processes. The proposed pattern tries to create a mutex with a certain name and checks if this mutex already existed. If it did, this means that our process was already started.

Here are the details that are important:

The mutex must be declared static, because we have to make sure that the garbage collector will never dispose it.
The name of the mutex should contain a GUID, which ensures that no other application uses the same name. If you don’t know how to create a GUID, click here.
The mutex is local, which means that every user that is logged on can create his own instance. If you don’t want this, simply ommit the ‘Local\\’.
The mutex contains the name of the application. As a general guideline, I think that named kernel objects should have a descriptive name. This makes it easier when debugging problems: using tools such as SysInternal’s WinObj, you can look at the state of all the kernel objects. If your object has a proper name this will be much simpler.

GDI+ objects should be disposed

2008-11-19T08:47:00.001+01:00

When a Winforms-control needs to do custom painting, this is typically done by overriding the OnPaint-method like this:

        1: protected override void OnPaint(PaintEventArgs e)

       2: {

       3:     base.OnPaint(e);

       4:  

       5:     Graphics g = e.Graphics;

       6:  

       7:     // WARNING: this code should be avoided because it does not dispose the GDI+ objects

       8:     g.FillRectangle(new SolidBrush(Color.Black), this.ClientRectangle);

       9:     TextRenderer.DrawText(g, "Hello world!", new Font(FontFamily.GenericSansSerif, 10f), new Point(10, 10), Color.White);

      10:     g.DrawLine(new Pen(Color.White), new Point(0, 0), new Point(100,100));

      11: }

On the internet you will find lots of example code that does custom drawing like this. The problem is that every time this code is executed (and in GUI this can be a lot!), a bunch of GDI+ objects are created that are not disposed. Eventually the garbage collector will kick in and will dispose all these objects. This is to be avoided however:

This puts a lot of stress on the garbage collector.
These objects will be cleaned up in two fazes which will impact performance even more.
GDI+ handles are limited resources, but the garbage collector is only invoked if your application needs more memory. It is not unlikely that your code uses a lot of GDI+ handles but does not consume a lot of memory. This may mean that the garbage collector never executes, and your code may consume a huge amount of GDI+ handles.
This issue was especially problematic before GC.AddMemoryPressure() was added in .NET 2.

The obvious solution is to dispose the GDI+ objects when they are not needed anymore:

       1: protected override void OnPaint(PaintEventArgs e)

       2: {

       3:     base.OnPaint(e);

       4:  

       5:     Graphics g = e.Graphics;

       6:  

       7:     // Much better: less stress on the garbage collector

       8:     using (SolidBrush brush = new SolidBrush(Color.Black))

       9:     using (Font font = new Font(FontFamily.GenericSansSerif, 10f))

      10:     using (Pen pen = new Pen(Color.White))

      11:     {

      12:         g.FillRectangle(brush, this.ClientRectangle);

      13:         TextRenderer.DrawText(g, "Hello world!", font, new Point(10, 10), Color.White);

      14:         g.DrawLine(pen, new Point(0, 0), new Point(100,100));

      15:     }

      16: }

This code is good but we can make it even better. Note that every time the code is executed, new GDI+ objects are created and disposed. In this particular case this is a waste because the objects will be identical every time. It would be better to create the objects only once, and reuse them every time.

It seems that the Winforms-designers at Microsoft also had this idea, because they already cache the commonly used brushes and pens in the Brushes and Pens classes. For the Font-object we need to do this ourselves:

       1: static readonly Font s_Font = new Font(FontFamily.GenericSansSerif, 10f);

       2:  

       3: protected override void OnPaint(PaintEventArgs e)

       4: {

       5:     base.OnPaint(e);

       6:  

       7:     Graphics g = e.Graphics;

       8:  

       9:     g.FillRectangle(Brushes.Black, this.ClientRectangle);

      10:     TextRenderer.DrawText(g, "Hello world!", s_Font, new Point(10, 10), Color.White);

      11:     g.DrawLine(Pens.White, new Point(0, 0), new Point(100,100));

      12: }

Notice that our Font-instance is declared as static because it can be reused when there are many instances of our control.

Of course this technique can only be used if the GDI+ objects are the same every time. If they are highly dynamic then you will have to create a new object every time (this may occur if you are drawing a part of an animation). But don’t forget to dispose these objects with the using-statement.

A Winforms-control should not subscribe to its own events

2008-11-12T08:01:00.001+01:00

Each Winforms-control defines many events that can be used to receive all kinds of notifications. Often I see that a control subscribes to its own events, for example:

        1: // this code is added by the designer in the InitializeComponent() method

       2: this.Load += new System.EventHandler(this.Form1_Load);

       3:  

       4: private void Form1_Load(object sender, EventArgs e)

       5: {

       6:     ...

       7: }

This will work OK, but events are conceptually not so simple. They are needed when you need a loose coupling between the publisher and the subscriber. This makes no sense if the publisher and the subscriber are the same control.

There is an alternative that is much simpler: for each event, there is also a virtual method that can be overridden:

       1: protected override void OnLoad(EventArgs e)

       2: {

       3:     base.OnLoad(e);

       4:  

       5:     ...

       6: }

This alternative will also have a slightly better performance. However, you should not forget to call the base-implementation (luckily, this call will be added automatically by IntelliSense). The base-implementation will raise the event, so if you omit this then the other parts of the code will not receive this event from your control.

Casting an array of value types

2008-11-05T10:32:00.001+01:00

Warning ahead: this article explains a dirty trick that should only be used in very specific circumstances (when memory conditions are low). I’ve personally seen this used when loading a large image from file (as a byte array) and needing to pass this array to a piece of legacy code that only accepts an array of shorts. Due to the size of the image, it was not feasible to copy the data.

Casting arrays of value types can be problematic. Image that you need to cast a large array of unsigned integers to an array of signed integers.

Our first experiment might be like this:

        1: static int[] Cast(uint[] input)

       2: {

       3:     int[] result = new int[input.Length];

       4:     

       5:     Array.Copy(input, result, input.Length);    // throws ArrayTypeMismatchException

       6:  

       7:     return result;

       8: }

This does not work. We get an ArrayTypeMismatchException because the two types are not compatible (the rules for compatible types are explained here).

The solution is to use the Marshal.Copy() method. This requires unsafe code however.
Here is an example:

       1: static unsafe int[] Cast(uint[] input)

       2: {

       3:     int[] result = new int[input.Length];

       4:  

       5:     fixed(uint* pInput = input)

       6:     {

       7:         Marshal.Copy(new IntPtr(pInput),result,0, input.Length);

       8:     }

       9:  

      10:     return result;

      11: }

This seems to work, but instead of casting the array we really made a copy of the array. The differences are subtle but can be important:

the copy requires its own memory. If the array is very large, this can be a problem. I’ve encountered situations (e.g. in image processing) where this was not acceptable.
when the copy is modified, the original array is left untouched. This is not what should happen when we cast a variable.

Using a dirty trick it is possible to cast an array of value types without copying the data. Look at this sample code:

       1: // WARNING: this is a dirty trick. Use at your own risk!

       2: static int[] Convert(uint[] input)

       3: {

       4:     Converter converter = new Converter();

       5:     converter.UInts = input;

       6:     return converter.Ints;

       7: }

       8:  

       9: [StructLayout(LayoutKind.Explicit)]

      10: struct Converter

      11: {

      12:     [FieldOffset(0)]

      13:     public int[] Ints;

      14:  

      15:     [FieldOffset(0)]

      16:     public uint[] UInts;

      17: }

We’re using a Converter-struct that uses some interop-magic to define two fields that map to the same location in memory. Now we can access the same data as an int[] or as an uint[]. The data is not copied in any way!

Note that this is a dirty trick: we fool the compiler into thinking that the type of the array is changed but it really is not. You can verify this by calling GetType() on the returned array: it will return System.UInt32[].

This trick can be used in other situations as well, for instance to access an array of integers as an array of bytes (without copying the data).

Warning: if the size of the array to be converted is reasonably small, you should just copy the data! Only use this trick if you really cannot afford to copy the data! This trick violates the type-safety of the runtime and is not guarantee to work in all situations or in future versions of .NET!

Removing items from a collection

2008-10-29T08:11:00.001+01:00

A common coding pattern is removing items from a collection based on the value of the items. The simplest way to do this is to enumerate the collection, and remove all the items that you don't want.

Code example:

        1: List<string> colors = new List<string>();

       2: colors.Add("red");

       3: colors.Add("green");

       4: colors.Add("blue");

       5:  

       6: foreach (string color in colors) // WARNING: this code will throw an exception

       7: {

       8:     if (color == "green") colors.Remove("green");

       9: }

However, doing this will throw this exception: System.InvalidOperationException: Collection was modified; enumeration operation may not execute. It seems that the enumerator is invalid after the collection has been modified.

There are several ways to work around this behavior.

1 Store the items to be removed in a temporary collection

This approach is really simple: instead of immedeately removing the items, we keep them in a separate collection. In the end, after the original list has been enumerated, we remove all these items.

Code example:

       1: List<string> colors = new List<string>();

       2: colors.Add("red");

       3: colors.Add("green");

       4: colors.Add("blue");

       5:  

       6: List<string> itemsToRemove = new List<string>();

       7: foreach (string color in colors)

       8: {

       9:     if (color == "green") itemsToRemove.Add("green");

      10: }

      11:  

      12: foreach (string itemToRemove in itemsToRemove) colors.Remove(itemToRemove);

In most situations this approach works very well. Only in very large collections, the itemsToRemove collection may become very big and consume a lot of memory. In my experience this is seldom the case.

2 Iterate the collection from back to front

This alternative uses a for-loop to iterate the collection from the back to the front.

Code example:

       1: List<string> colors = new List<string>();

       2: colors.Add("red");

       3: colors.Add("green");

       4: colors.Add("blue");

       5:  

       6: for (int counter = colors.Count - 1; counter >= 0; counter--)

       7: {

       8:     if (colors[counter] == "green") colors.RemoveAt(counter);

       9: }

Here we do not need a temporary collection. It is also slightly more efficient because we can remove the item based on its index. This means that the collection does not have to search for the item that has to be removed (as was the case in the first approach).

3 Using a predicate

The third alternative is only available from .NET 2 onwards. The List-collection implements a RemoveAll() method that takes a predicate as a parameter. Simply put, a predicate is a delegate that is used for filtering. In this case, the predicate returns true for each item that needs to be removed.

In this code example, the predicate is implemented as an anonymous method:

       1: List<string> colors = new List<string>();

       2: colors.Add("red");

       3: colors.Add("green");

       4: colors.Add("blue");

       5:  

       6: colors.RemoveAll(delegate(string color)

       7: {

       8:     return color == "green";

       9: });

This approach has some benefits:

It is self-documenting.
We don’t have to worry about the performance, we can assume that the RemoveAll() method is implemented in the most efficient way. If the internals of the collection-class would later change, the RemoveAll() method will likely be changed as well to keep the best performance.

A type-safe pattern to implement ICloneable and similar interfaces

2008-10-22T08:03:00.001+02:00

The ICloneable interface contains a single method Clone() that returns a clone of the object.

However the return value is defined as type ‘System.Object’, which means that the user still has to cast this to the actual type:

        1: Test t = new Test();

       2: Test t2 = t.Clone() as Test;    // cast needed

This is cumbersome and error-prone because the cast may fail at runtime.

Use the following pattern to provide a type-safe implementation of this interface:

       1: class Test : ICloneable

       2: {

       3:     int m_Amount;  // just some example data...

       4:     Font m_Font;

       5:     string m_Name;

       6:  

       7:     #region ICloneable Members

       8:  

       9:     // Provide a type-safe implementation

      10:     public Test Clone()

      11:     {

      12:         Test clone = new Test();

      13:         clone.m_Amount = m_Amount;

      14:         clone.m_Font = m_Font.Clone() as Font;

      15:         clone.m_Name = m_Name;

      16:         return clone;

      17:     }

      18:  

      19:     // Provide an "Explicit Interface Method Implementation"

      20:     object ICloneable.Clone()

      21:     {

      22:         return Clone();

      23:     }

      24:  

      25:     #endregion

      26: }

This example implements a type-safe Clone() method, so the user does not have to cast the result. But we still have to implement the interface-method that returns a System.Object. This is done through explicit interface method implementation.

This pattern is easier for the user of the class, and it has the benefit that the compiler will now guarantee that the returned object is always of the correct type.

Beware of the stopwatch

2008-10-15T08:31:00.001+02:00

In a comment on my last post, craniac argued that the StopWatch-class should be used for measuring time intervals.

Sadly, measuring a time interval is not as easy as it sounds. There are several mechanisms, I will explain 3 of them and point out their strengths and weaknesses.

1. DateTime.UtcNow

        1: DateTime begin = DateTime.UtcNow;

       2:  

       3: ...

       4:  

       5: DateTime end = DateTime.UtcNow;

       6: Console.WriteLine("Measured time: " + (end-begin).TotalMilliseconds + " ms.");

This is the fastest mechanism because under the hood it only reads a counter from memory (the code above takes only 76 nanoseconds to execute on my machine). However the resolution is not so great: only 10 milliseconds on recent version of Windows. If you want to measure a piece of code that takes shorter to execute, you will have to execute it e.g. 1000 times and measure how long this takes, then divide the result by 1000.

Another disadvantage is that this is not reliable if the system-time changes. This should be a very rare situation, but could for instance happen through synchronization with a time server.

2. Stopwatch

       1: Stopwatch watch = new Stopwatch();

       2: watch.Start();

       3:  

       4: ...

       5:  

       6: watch.Stop();

       7: Console.WriteLine("Measured time: " + watch.Elapsed.TotalMilliseconds + " ms.");

This mechanism is a bit slower than the previous one (10 times slower on my machine) so for short intervals this may have an impact on the result. However there are some serious issues:

This can be unreliable on a PC with multiple processors. Due to a bug in the BIOS, Start() and Stop() must be executed on the same processor to get a correct result.
This is unreliable on processors that do not have a constant clock speed (most processors can reduce the clock speed to conserve energy). This is explained in detail here.

I suspect that you can get a reliable result if you run it on a single-processor machine and disable any power-saving options in the BIOS. I haven’t tested this though.

On the upside, it has the hightest possible resolution (which depends on the hardware it runs on).

3. Process.TotalProcessorTime

       1: TimeSpan begin = Process.GetCurrentProcess().TotalProcessorTime;

       2:  

       3: ...

       4:  

       5: TimeSpan end = Process.GetCurrentProcess().TotalProcessorTime;

       6: Console.WriteLine("Measured time: " + (end - begin).TotalMilliseconds + " ms.");

This mechanism is different from the previous ones because it does not measure how much time has passed, but it measures how long your process has kept the CPU busy. This is great for performance measurements:

The timings are not distorted by other processes that consume a lot of CPU.
You can measure the impact that your code has on the overall performance of the system. On laptops, this also gives an indication towards the battery-power that is consumed by your process. This can be important for applications that run for a long time (such as services and other background tasks).

To interpret the measured time correctly, you should realize that time that is spent while your code is waiting (e.g. in a Sleep) will not be counted. On the other hand, if your process is keeping multiple processors busy, the time of each processor will be added (if a dual-core processor is kept 100% busy, the ‘TotalProcessorTime’ will increment with 2 each second!).

Note that this mechanism has the worst performance: the code above takes 19264 nanoseconds on my PC. This is 250 times slower than using DateTime.UtcNow!

So there is not one-size-fits-all solution to measure a time interval. Personally, if I want to measure how long a piece of code takes to execute, I run it in a loop (e.g. one million times) and measure it using DateTime.UtcNow.

Sometimes it is better to use DateTime.UtcNow instead of DateTime.Now

2008-10-08T09:03:00.001+02:00

When you want to measure how long a certain action takes, you should use DateTime.UtcNow instead of DateTime.Now:

        1: DateTime begin = DateTime.UtcNow;

       2:  

       3: ...

       4:  

       5: DateTime end = DateTime.UtcNow;

       6: MessageBox.Show("Time taken: " + (end-begin).TotalMilliseconds);

Reasons:

DateTime.UtcNow is more efficient than DateTime.Now (on my PC: 21 nanoseconds versus 575 nanoseconds).
More importantly: DateTime.Now will get you into trouble if Daylight Saving Time is enabled. For instance, it is possible that begin contains 02:59:00 and end contains 02:01:00 (while only two minutes have elapsed).

Of course, both mechanisms are incorrect if the user changes his clock (manually or through synchronziation with a time server).

Avoid invoking a virtual method in a constructor

2008-10-01T10:08:00.001+02:00

You should be very careful when invoking a virtual method in the constructor of a class that is not sealed.

Reason: when the virtual method is overriden in a derived class, this method will be invoked even before the constructor of the derived class has been invoked! This probably was not anticipated by the developer of the derived class!

Take for instance this example:

        1: abstract class Base

       2: {

       3:     public Base() // This constructor calls a virtual method

       4:     {

       5:         Initialize();

       6:     }

       7:  

       8:     protected abstract void Initialize();

       9: }

      10:  

      11: class Derived : Base

      12: {

      13:     FileStream m_File;

      14:  

      15:     public Derived()

      16:     {

      17:         m_File = new FileStream(@"c:\temp\test.txt", FileMode.Open);

      18:     }

      19:  

      20:     protected override void Initialize()

      21:     {

      22:         MessageBox.Show(m_File.Length.ToString());    // NullReferenceException! m_File has not been constructed yet!

      23:     }

      24: }

When an instance of Derived is created, first the constructor of the base class is called. This will result in Derived.Initialize() being called before the constructor of Derived has executed!

Because this is very contra-intuitive, it is best not to invoke virtual methods from a constructor altogether. Except when the class is sealed of course, because then there can be no derived class.

Prevent indentation by combining using-statements

2008-09-24T08:15:00.001+02:00

C# code tends to be heavily indented:

All code is indented at least three levels deep (namespace, class, method).
The usage of constructs such as using and try-finally adds further indentation.

Especially in GDI+ drawing code, the usage of using-statements can make the code much more difficult to read:

        1: protected override void OnPaint(PaintEventArgs e)

       2: {

       3:     base.OnPaint(e);

       4:  

       5:     using (Pen thickBlack = new Pen(Color.Black, 5f))

       6:     {

       7:         using (Pen thickRed = new Pen(Color.Red, 5f))

       8:         {

       9:             using (LinearGradientBrush backGround = new LinearGradientBrush(...)

      10:             {

      11:                 // start painting here...

      12:             }

      13:         }

      14:     }

      15: }

This can be simplified by combining the using-statements like this:

       1: protected override void OnPaint(PaintEventArgs e)

       2: {

       3:     base.OnPaint(e);

       4:  

       5:     using (Pen thickBlack = new Pen(Color.Black, 5f))

       6:     using (Pen thickRed = new Pen(Color.Red, 5f))

       7:     using (LinearGradientBrush backGround = new LinearGradientBrush(...)

       8:     {

       9:         // start painting here...

      10:     }

      11: }

As you can see this reduces indentation, making the code easier to read and understand.

Prevent unnecessary indentation

2008-09-17T08:44:00.001+02:00

Code that is heavily indented is difficult to read (especially if the method does not fit on a single screen anymore).

Instead of this code …

        1: void Test(string input)

       2: {

       3:   if (input != null)

       4:   {

       5:     if (input.Length > 0)

       6:     {

       7:       …

       8:     }

       9:   }

      10: }

… write this code:

       1: void Test(string input)

       2: {

       3:   if (input == null) return;

       4:   if (input.Length == 0) return;

       5:  

       6:   …

       7: }

How to use consistent version numbering across multiple projects

2008-09-05T15:47:00.001+02:00

If you have many C# projects, you may want all your assemblies to have the same version numbers. Remember that the version numbers are defined in the ‘AssemblyInfo.cs’ file in each project.

There are several mechanisms to achieve this:

Programmatically change all the ‘AssemblyInfo.cs’-files to update the version number.
You could write a tool that updates the version number of all your projects. This tool could then be integrated in your build process. This is cumbersome and often not so simple if your projects are checked in a source control system.
Define the version-numbers in a single file that is used by all your projects. This technique is explained in this article.
Define the version-numbers in a separate assembly that is referenced by all projects.

In this post I will elaborate on the third mechanism (because I’ve never seen this explained anywhere else).

Create a new C# project (called Metadata.csproj) that contains all the metadata that is shared across your projects. This project is very simple and contains only 1 class:

        1: namespace KristofVerbiest

       2: {

       3:     public static class ProjectMetadata

       4:     {

       5:         public const string FileVersion = "1.5.0.1";

       6:         public const string CompanyName = "Kristof Verbiest";

       7:         public const string Copyright = "Copyright © Kristof Verbiest 2008";

       8:     }

       9: }

Now you can reference this assembly from all your other C# projects, and you can use the data from the ‘AssemblyInfo.cs’ files like this:

       1: [assembly: AssemblyFileVersion(ProjectMetadata.FileVersion)]

       2: [assembly: AssemblyCompany(ProjectMetadata.CompanyName)]

       3: [assembly: AssemblyCopyright(ProjectMetadata.CopyRight)]

Note that the ‘Metadata.dll’ assembly is used by the compiler to fill in the correct metadata. However this assembly is not needed at runtime! So you don’t need to deploy this assembly to your users, it is only needed by the compiler.

Assume that someone who is less experienced than you needs to understand your code

2008-09-03T11:29:00.001+02:00

Transparency is an important aspect in a project where many developers are working on the same software.

Some developers like to show of how smart they are using complex constructs that are difficult to understand. This is unnecessary and not fair towards their colleagues.

Some examples:

Unnecessary usage of the ?: operator and the null coalescing operator. These operators are not commonly known and should only be used if they improve the readability of the code.
Complex expressions whose output depends on the operator precedence rules.
Usage of anonymous methods.
Usage of regular expressions. Regular expressions can be very powerful, but they have the nasty habbit that they tend to be easier to write than to read.
Consider rewriting your logic using simple string actions. If you really need to use regular expressions, you should document them very well.

If you encounter a situation where one of these techniques really makes sense then of course you should use it. But you should also add some documentation why you are doing it (and maybe include a link to a website that explains the technique).

Good code is self-documenting

2008-08-27T09:33:00.001+02:00

Picking a good name for a class/method is often very difficult. But if the names are chosen carefully the code often needs no further documentation.

For instance compare these two simple examples (they are functionally equivalent):

        1: /// <summary>

       2: /// Summary for Bounds class

       3: /// </summary>

       4: public class Bounds

       5: {

       6:   public int m_A;    // lower bound

       7:   public int m_B;    // upper bound

       8:  

       9:   /// <summary>

      10:   /// Creates a new Class1 instance

      11:   /// </summary>

      12:   /// <param name="a">the lower bound</param>

      13:   /// <param name="b">the upper bound</param>

      14:   public Bounds(int a, int b)

      15:   {

      16:     // m_A should be the smallest value

      17:     m_A = Math.Min(a, b);

      18:     // m_B should be the biggest value

      19:     m_B = Math.Max(a, b);

      20:   }

      21:   …

      22: }

       1: public class Bounds

       2: {

       3:   public int m_LowerBound;

       4:   public int m_UpperBound;

       5:  

       6:   /// <remarks>It is OK to provide a & b in the wrong order.</remarks>

       7:   public Bounds(int a, int b)

       8:   {

       9:     // The rest of this class assumes that m_Lowerbound <= m_Upperbound,

      10:     // so we fix it here

      11:     m_LowerBound = Math.Min(lowerBound, upperBound);

      12:     m_UpperBound = Math.Max(lowerBound, upperBound);

      13:   }

      14:   …

      15: }

Although the second example has less comments, I feel that it is better documented because it is self-describing:

The default class-comment that is inserted by Visual Studio is useless. The name of the class is already sufficient documentation.
The second example has good names for the fields; further comments are not necessary.
The first example has comments about stuff that is very obvious (every developer should already know what a constructor does).
The first example explains the sorting of the parameters but every developer can see what is going on. The second example instead explains why the parameters need to be sorted.

If your code is written cleanly then you don’t have to document what it is doing. But you may have to document why it is doing it.

Don’t use a dedicated thread to wait on a kernel object

2008-08-20T09:51:00.001+02:00

One of the code patterns in the previous post showed that you don’t need a dedicated thread to execute a piece of code at regular intervals.

Likewise you don’t need a dedicated thread to wait on a kernel object (such as a mutex or an event). You can use the threadpool to do this:

        1: class Test

       2: {

       3:   // This method returns an event. Whenever the event will be set (by the caller of this 

       4:   // method), the 'EventWasSet' method will be executed.

       5:   public WaitHandle GetEvent()

       6:   {

       7:     AutoResetEvent m_Event = new AutoResetEvent(false);

       8:     ThreadPool.RegisterWaitForSingleObject(m_Event, EventWasSet, null, Timeout.Infinite,false);

       9:     return m_Event;

      10:   }

      11:  

      12:   void EventWasSet(object state, bool timeOut)

      13:   {

      14:     // This code will be executed on the threadpool when the event is set

      15:   }

      16: }

The RegisterWaitForSingleObject() method makes sure that the given method will be executed on a threadpool thread when the kernel object is signaled.

Timers: executing a task at regular intervals

2008-08-13T09:22:00.001+02:00

When you want to execute a piece of code at regular intervals, you should not start a dedicated thread to do this. Instead you should use a timer.

If the task you want to perform involves GUI interaction, it is best to use the Windows.Forms.Timer class. An example:

        1: class Test

       2: {

       3:   System.Windows.Forms.Timer m_Timer = new System.Windows.Forms.Timer();

       4:  

       5:   public void StartTimer()

       6:   {

       7:     m_Timer.Interval = 1000;    // tick every 1000 ms

       8:     m_Timer.Tick += Timer_Tick;

       9:     m_Timer.Start();

      10:   }

      11:  

      12:   void Timer_Tick(object sender, EventArgs e)

      13:   {

      14:     // This code will execute every second on the GUI thread

      15:   }

      16: }

If the code does not involve GUI interaction, it is best to use a threadpool-timer. However you need to be careful: if your code takes longer to execute than the interval of the timer, you will cause threadpool starvation! This occurs if the maximum amount of threadpool-threads is reached. This will cause serious problems for the complete process because all code that uses the threadpool (including .NET Remoting) will be blocked.

As a workaround you can set the timer to execute only once, and reset it every time it has executed:

       1: class Test

       2: {

       3:   System.Threading.Timer m_Timer;

       4:  

       5:   public void StartTimer()

       6:   {

       7:     // set timer to be executed only once

       8:     m_Timer = new System.Threading.Timer(Timer_Tick,null,1000,0);

       9:   }

      10:  

      11:   void Timer_Tick(object state)

      12:   {

      13:     try

      14:     {

      15:       // This code will execute every second on a threadpool thread

      16:     }

      17:     finally

      18:     {

      19:       // reset the timer

      20:       m_Timer.Change(1000, 0);

      21:     }

      22:   }

      23: }

So there is no need to start a dedicated thread just to perform a piece of code at regular intervals.