Brendan Enrick

Daily Software Development

Try Catch Performance in CSharp: A Simple Test Response

I read an interesting little post about a Try Except Performance Test Using Python written by Patrick Altman. As he mentioned, I have also had discussions with people about this exact topic in the past plenty of times. He was testing the performance issue of whether it is better to use a try catch block to handle possible errors or to check for them before they're a problem.

He handled 2 different cases; the success and the failure. Using loops he performed time checks on these to see how long it took. I thought it was very interesting, but the nice question is how does this hold up using C#. So I also wrote a simple little test similar to his. The results are pretty interesting. Keep in mind this just gives some rough estimates on this.

 

The case where the key does not exist:
1,000 iterations:
Try_NotExist(1000) = 00:00:00.0852580
Without_Try_NotExist(1000) = 00:00:00.0000089
Without_Try_NotExist_Not(1000) = 00:00:00.0000089
100,000 iterations:
Try_NotExist(100000) = 00:00:06.1590461
Without_Try_NotExist(100000) = 00:00:00.0006802
Without_Try_NotExist_Not(100000) = 00:00:00.0006799
1,000,000 iterations:
Try_NotExist(1000000) = 00:01:02.8172468
Without_Try_NotExist(1000000) = 00:00:00.0070592
Without_Try_NotExist_Not(1000000) = 00:00:00.0092609

The case where the key does exist:
1,000 iterations:
Try_Exist(1000) = 00:00:00.0000083
Without_Try_Exist(1000) = 00:00:00.0000117
Without_Try_Exist_Not(1000) = 00:00:00.0000117
100,000 iterations:
Try_Exist(100000) = 00:00:00.0006185
Without_Try_Exist(100000) = 00:00:00.0008624
Without_Try_Exist_Not(100000) = 00:00:00.0008492
1,000,000 iterations:
Try_Exist(1000000) = 00:00:00.0088896
Without_Try_Exist(1000000) = 00:00:00.0086661
Without_Try_Exist_Not(1000000) = 00:00:00.0097892

As you can see here my results are somewhat similar to the findings Patrick found. If it is going to fail often at all you're much better off checking for the error before it fails because of how immense the difference between handling the error and not is. However if pretty much every time the code will succeed without any errors, you're better off with the try-catch block by a very small amount. The fact that it is only a small amount better tells me that I am much better off checking for an error than I am using a try-catch block to trap the error.

And so you can try for yourself or inform me of any errors I've made I'll include my code.

using System;
using System.Diagnostics;
using System.Text;

namespace Try_Catch_Performance
{
    class Program
    {
        private static int[] x = { 0 };
        private static int ExistIndex = 0;
        private static int NotExistIndex = 1;

        private static void Try_NotExist(int iterations)
        {
            Stopwatch st = new Stopwatch();
            st.Start();
            for (int i = 0; i < iterations; i++)
            {
                try
                {
                    int y = x[NotExistIndex];
                }
                catch (Exception)
                {
                }
            }
            st.Stop();
            Console.WriteLine("Try_NotExist({0}) = {1}", iterations, st.Elapsed);
        }

        private static void Without_Try_NotExist(int iterations)
        {
            Stopwatch st = new Stopwatch();
            st.Start();
            for (int i = 0; i < iterations; i++)
            {
                if (x.Length > NotExistIndex)
                {
                    int y = x[NotExistIndex];
                }
            }
            st.Stop();
            Console.WriteLine("Without_Try_NotExist({0}) = {1}", iterations, st.Elapsed);
        }

        private static void Without_Try_NotExist_Not(int iterations)
        {
            Stopwatch st = new Stopwatch();
            st.Start();
            for (int i = 0; i < iterations; i++)
            {
                if (!(x.Length <= NotExistIndex))
                {
                    int y = x[NotExistIndex];
                }
            }
            st.Stop();
            Console.WriteLine("Without_Try_NotExist_Not({0}) = {1}", iterations, st.Elapsed);
        }

        private static void Try_Exist(int iterations)
        {
            Stopwatch st = new Stopwatch();
            st.Start();
            for (int i = 0; i < iterations; i++)
            {
                try
                {
                    int y = x[ExistIndex];
                }
                catch (Exception)
                {
                }
            }
            st.Stop();
            Console.WriteLine("Try_Exist({0}) = {1}", iterations, st.Elapsed);
        }

        private static void Without_Try_Exist(int iterations)
        {
            Stopwatch st = new Stopwatch();
            st.Start();
            for (int i = 0; i < iterations; i++)
            {
                if (x.Length > ExistIndex)
                {
                    int y = x[ExistIndex];
                }
            }
            st.Stop();
            Console.WriteLine("Without_Try_Exist({0}) = {1}", iterations, st.Elapsed);
        }

        private static void Without_Try_Exist_Not(int iterations)
        {
            Stopwatch st = new Stopwatch();
            st.Start();
            for (int i = 0; i < iterations; i++)
            {
                if (!(x.Length <= ExistIndex))
                {
                    int y = x[ExistIndex];
                }
            }
            st.Stop();
            Console.WriteLine("Without_Try_Exist_Not({0}) = {1}", iterations, st.Elapsed);
        }

        static void Main(string[] args)
        {
            Console.WriteLine("The case where the key does not exist:");
            Console.WriteLine("1,000 iterations:");
            Try_NotExist(1000);
            Without_Try_NotExist(1000);
            Without_Try_NotExist_Not(1000);
            Console.WriteLine("100,000 iterations:");
            Try_NotExist(100000);
            Without_Try_NotExist(100000);
            Without_Try_NotExist_Not(100000);
            Console.WriteLine("1,000,000 iterations:");
            Try_NotExist(1000000);
            Without_Try_NotExist(1000000);
            Without_Try_NotExist_Not(1000000);

            Console.WriteLine("The case where the key does exist:");
            Console.WriteLine("1,000 iterations:");
            Try_Exist(1000);
            Without_Try_Exist(1000);
            Without_Try_Exist_Not(1000);
            Console.WriteLine("100,000 iterations:");
            Try_Exist(100000);
            Without_Try_Exist(100000);
            Without_Try_Exist_Not(100000);
            Console.WriteLine("1,000,000 iterations:");
            Try_Exist(1000000);
            Without_Try_Exist(1000000);
            Without_Try_Exist_Not(1000000);
        }
    }
}

Happy Error Checking!

Explicitly and Implicitly Implementing Interfaces

I read an interesting blog post from Joydip Kanjilal where he described an interesting little trick with interfaces. I, being a bit of a fan of interfaces, read the post and thought I'd throw my $0.02 in also. I couldn't pass up an opportunity to talk about interfaces. He first shows simply how to create an interface and how to implement the interface implicitly. The difference between implicitly and explicitly writing this code is what creates the different circumstances Joydip shows in his demonstration.

I'll start where he did with an interface. I'll name my interface IBloggable and I'll have a class PostContent which implements the interface.

public interface IBloggable
{
    void SendToBlog();
}

public class PostContent : IBloggable
{
    public void SendToBlog()
    {
        // Send this content to a blog
    }
}

Ok so this is the implicit implementation of the interface. Basically all I mean when I say explicitly and implicitly is whether or not you're going to define everything. If I define something explicitly I have defined everything and made it perfectly clear. I have included every detail required for precise interpretation. Notice above I have not specified to which class that method applies. So here I will now define the same thing explicitly and make sure that the SendToBlog method specifies to what it belongs.

public class PostContent
{
    void IBloggable.SendToBlog()
    {
        // Send to blog only for the interface not for implementing classes
    }
}

As Joydip pointed out so well, the first one will work in either of these circumstances, but our explicitly defined method will only work in the first example.

Example 1:

IBloggable b = new PostContent();

Example 2:

PostContent b = new PostContent();

From this we can note a couple of other interesting points here.

If we implement interface methods implicitly, we are able to use the method with objects of the interface type or of the implementing class type. If we are implementing explicitly, the method will only work on the interface. The great benefit of only allowing instances of the interface to use the method is that it encourages you to write more dynamic and maintainable code since you'll be using the interface everywhere you'll be able to switch your implementing classes quickly and easily.

This is one of many great ways to write better code. I always explicitly implement my interfaces. I've not had it bite me yet, so if anyone knows a reason to not explicitly define this code, please let me know.

One nice feature in Visual Studio which makes this nice and easy. Once you specify the interface you want your class to implement you are able to right click on it and choose Implement Interface > Implement Interface Explicitly and it will create the stubs for everything required in order to implement the interface. It will even place it all in a nice code region for you. Observe the code it generates for us in this instance.

public class PostContent : IBloggable
{
    #region IBloggable Members

    void IBloggable.SendToBlog()
    {
        throw new Exception("The method or operation is not implemented.");
    }

    #endregion
}

Happy coding.

Introduction to Partial Classes

I've recently written a beginner's article explaining what partial classes are and how to use them. My Partial Classes Tutorial walks you through how how partial classes work, how to create partial classes, when one would use partial classes, and a few other bits of useful information. If you don't know much about partial classes I recommend you read the article it has some useful information in it. If you have any partial class question either ask me here or comment on the article. I will be happy to answer questions.

As always, thank you very much for reading.

Static Methods and Interfaces in C#

Someone just commented on my C# interfaces article on ASP Alliance asking an interesting question, and I figure I will respond to it here since I can give a better response here. I don't want to clutter the article comments. Also I can add nifty cool pictures, format all of my text nicely, and write a heck of a lot more here.

This is the excellent question I was asked.

All my classes implementing my interface should have a static funtion.
Why can't I have a static function in an interface???

-Jan

This is how I responded in the article.

One important thing to understand about static methods is that they don't really need to be tied to classes. Static methods basically just exist for convenience.
An interface is as the name says an interface to something. Think of it like an automobile interface. There are defined ways of working with the car. They have a steering wheel a gas pedal and brakes. An interface defines that and all automobiles will have those, but an interface doesn't define anything about "cars in general" (static) it defines what will be the interface for individual cars (instances).

As I was saying interfaces are used for defining interfaces for code. I like my car analogy, but I think I'll use a sail boat analogy this time.

Think of writing an interface in C# called ISailable. This objects implementing this interface will be sailboats. So what does every sailboat need to be able to function. For simplicity I'll say that we just need to have sails and a wheel. All sailboats will also need to be able to sail. So now we've defined how our ISailable objects work. We can now create sailboats using this nice interface. Notice we haven't defined how large the sails are or what style of sails. We just said we need sails. We also did not define the wheel. Is it metal or wood? How large is it? We don't care in the interface the classes implementing the interface will each define those differently. Notice that different boats have very different types of sails.

We might define out ISailable interface in the following way. Keep in mind I am using a lot of simplicity here.

namespace Enrick.Interfaces
{
    public interface ISailable
    {
        void Sail(string destination);
        void Steer(string direction);
        void RaiseSails();
        void LowerSails();
    }
}

Then once we have that defined we are able to implement the interface and create our first sailable object which will of course be a sailboat.

namespace Enrick.Boats
{
    public class SailBoat : Enrick.Interfaces.ISailable
    {
        #region ISailable Members

        public void Sail(string destination)
        {
            // Write sailing logic here. It should be specific to this type of boat.
        }

        public void Steer(string direction)
        {
            // Write steering logic here for this exact type of boat.
        }

        public void RaiseSails()
        {
            // Write logic to raise these specific sails here.
        }

        public void LowerSails()
        {
            // Write logic to lower these specific sails here.
        }

        #endregion
    }
}

Static interfaces do not really apply to what we've defined though. We've just been talking about how to interface with individual sail boats. We haven't gotten to static methods really. This is because static methods aren't really necessary. Many languages have them, but they could just as easily be outside of the class and have the same functionality. Static methods are by definition methods which aren't specific to individual instances of classes. This means we could define these methods anywhere and achieve equivalent functionality. They also don't really apply with interfaces and the C# language specification doesn't allow static methods on interfaces because they don't really make sense with interfaces.

There are circumstances where someone might want to have a static method on an interface. Perhaps the static method was going to be a way of performing an action on an entire collection of the instances of the objects. Perhaps you have a fleet of ISailable ships that you will want to sail together. This would make sense to have a static method which would be associated with the class, but it isn't necessary. Instead we will create a static method elsewhere. It will not be tied to our interface. We can have it take a list of ISailable objects and then it can perform the sailing operation of our fleet.

public void SailFleet(List<ISailable> fleet, string direction)
{
    foreach (ISailable boat in fleet)
    {
        boat.Sail(direction);
    }
}

Notice here that I've defined a method which might have been static before on each of the boats and each one would have take a List of their instances, but that would be silly. This solution allows us to have methods which work with ISailable objects but they need not be defined as requiring an interface. Sadly there is not a way of having static methods on interfaces in C#.

I hope that answers some questions. As always, thanks for reading!

Great Conditional Logic

It is amazing some of the relics that can be found while code reviewing old code. Sometimes developers do things without thinking and make some great code. I am of course referring to some really funny code such as what I found a few minutes ago. I am always annoyed when boolean values are checked explicitly in conditional statements like the following code.

if (IsValid == true)

This bothers me because the true is completely useless. I would read this code as "If is valid is true", and that is kind of silly when I could say "If is valid".

if (IsValid)

This is just part of the annoyance in the code. Now I've cleaned it up a bit here, because it didn't really have a variable named IsValid. It was actually a variable named edit. We were not sure if edit meant that someone was allowed to edit or if it was in edit mode or what.

This was just slightly annoying. The really amazing part was in the else of this if statement. It had a great bit of else if logic. The code looked overall like this.

if (edit == true)
    // Lines of code here
else if (edit == false)
    // Lines of code here

I now wonder what possible other condition is there? In the else is there another state for edit? It is not a reference type, it is a value type so it can never be null. Just got to be careful of boolean operators there are so many other values for them other than true and false.

I hope everyone enjoyed this fun little code snippet.

An Explanation of Interfaces in C# for Beginners

I recently authored an article for ASP Alliance in which I describe the basics of how interfaces work and how to use and create them in C#. I tried not to describe in great detail exactly how everything works, because that will prevent beginners from understanding how interfaces may be used. I plan to write further about this topic, but I think it a mistake to begin with even an intermediate description of a topic without at least giving a beginners explanation first. I'll be doing some more advanced examples for my next article on interfaces, so look forward to one in the not too distant future.

I am not sure how the rest of you feel, but I think that interfaces are an amazing tool. I try to use interfaces when possible, because it makes code much more maintainable.

Let me know what you think and any suggestions for future articles.

As always, thanks for reading!

Using the as Statement to Cast Without Exceptions in C#

It is common to obtain variables with a type which is not the desired one. Considering that plenty of times there will be variables passed using the object data type, it is important to be able to cast your variables into more usable types. Say for example you're passed a variable as an object. You probably want to be able to access properties or methods of this object, so you will need to cast it into another class. The simple way of doing this is to use code similar to this.

DataTable myData = (DataTable)dataSource;

This works well, but is slightly more dangerous than it needs to be. The problem I have with casting it in this way is that the variable dataSource might not be a DataTable, and if this is the case we will throw an exception. Yes, we could wrap a try-catch block around this code, but I prefer to avoid exceptions when possible instead of catching them.

If we use the as statement we will be able to achieve the same result and just need a little bit of checking for an error. This way if our code is in an exceptional case we can handle it ourselves instead of having the overhead of a try-catch block. If the as statement receives an invalid cast it does not throw an exception. Instead of throwing the exception it merely places the null value instead. Since we receive the null value if the cast fails, we are now able to simply check for the null value.

DataTable myData = dataSource as DataTable;
if (myData != null)
{
    // Perform work here
}
else
{
    // Error handling code goes here. Perhaps a message of some kind.
}

As you can see we're able to avoid our exception and handle it without using a try-catch block. I am not advocating programs without these try-catch blocks. I am merely saying that I find it better to avoid catching exceptions that could have been avoided in the first place. I think some people become excessive with try-catch blocks. I've seen plenty of people write code which doesn't check strings for validity they instead just try working with them and if an exception occurs they catch it and respond. I think it is simply crazy.

Have a great day! Happy casting!

Knowing the Default Access Modifiers in C#

512px-PadlockI have a few friends in college who are learning C# on the side. I've been answering their questions when they ask. One interesting question was regarding access modifiers. I was asked which access modifiers are used by default in certain situations when there is not one specified.

First I'll quickly remind everyone of the access modifiers and what has permission to access them.

private - Any members of the same class have access.

protected - Any members of the same class or any derived class have access.

internal - All code in the same assembly. This means that it doesn't matter where the code is in the assembly. It can be in any class as long as it is inside of the same assembly it has access.

public - EVERYTHING HAS ACCESS!

When you define a data type of some kind (class, struct, enum, etc.) you need not specify an access modifier, but be aware that the default will be internal. This means that anything else in the assembly has access to it. There is very little sense for it to be private, because that would mean that only it has access to itself which means it would never do anything. Since we like the default permission to be as restrictive as possible it makes sense that the default is internal.

large_gold_keyThe other code with access modifiers are the members of the types we were just discussing. Since these are within a type private makes sense for them, and since we like keeping this locked down by default they use the private access modifier if no other is specified. This means they are only accessible by other members of the same thing. So a class might have a private member function and that function can only be called by other members of the class; functions, properties, etc.

Protected is probably my favorite access modifier to use, but since it is less restrictive it is not the default. This is because pretty much any time protected can be used so can private so private will be the default. Public is just way to open to be the default and C# doesn't want to encourage programmers to have everything be public. That is just a bad way to write code.

Don't get locked out because you don't know the default access modifier. Make sure you key in to the correct way of writing your code.

Have fun writing code with access modifiers!

Memory Management: Generics vs objects

One of the most important parts of software development is memory management. Memory management is important for every software application. If one is to write a well developed software application, one must have a fair bit of knowledge in the area of memory managament. It is important to understand the underlying technology which allows programs to function. There are many aspects of programs which come into play often in .NET applications; variables, functions, garbage collection.

Understanding Garbage Collection, Heaps, and Stacks

When using a language with a heap, it is important to understand that memory will be allocated dynamically. This is separate from where the basic program memory resides; the stack. On the stack memory builds as the program executes. Local variables are stored with the function information. This is the memory used in pretty much every language. When a heap is involved there is basically an area of memory where variables may be dynamically defined and only references to these variables are stored as pointers on the stack.

When the variable is out of scope or removed it is merely the reference to the variable which is removed. A garbage collector will come by later to free the memory for later use. Whenever there is not enough room to allocate memory in the heap the garbage collector wil come and clear unused memory.

Understanding Variable Types

There are basically two types of variables; value and reference. The value types tend to be the simpler variables and the reference types tend to be the more advanced variables. Some examples of value types are enums, ints, doubles, bools, chars, and structs. Some reference types are arrays, lists, and classes. The value types are the ones stored locally with the stack and the reference types are stored in the heap, and a reference to them is stored on the stack. When using the new keyword, memory is allocated on the heap and a referenced object is created.

Passing Parameters to Functions.

When passing variables as parameters to functions, it is important to understand the two main ways in which these variables may be passed. Variables may be passed by reference or by value. Passing by value means that we make a copy of the local variable and use that in the function. This means that our value type variable will be copied and if we use a reference type it means that only the reference will be copied. This means that we will still be accessing the same location in the heap even if we pass by value. By using the ref keyword you may pass a parameter by reference. This means for a value type you are able to just pass a reference to the original value. Do not pass a reference type by reference, because it will just make a reference to the reference to the value and that will slow things down for no reason. Passing by reference is a good idea if the value is large, so with a large struct you may want to pass by reference instead of copying all of the data.

Generics vs. Objects

When using parameters of type object, boxing and unboxing is used to take the variable and changing it to and from object. This seems pretty easy because one can simply add (object) when passing the parameter. The problem here is that this will create a new instance of an object. This means we will be making a copy of the variable instead of just using a reference to the variable. This will take time, and will also allocate extra memory which will need to be collected by the garbage collector later. This will also decrease the performance of our program. This is why it is important to use generics to prevent this performance hit. When we use generics we do not have to make a copy of the value, we merely pass a reference to the original value.

Be careful, and try to use Generics whenever possible. Your memory will thank you.

Understanding the Queue Data Structure Using a Simple C# Implementation

Introduction

Queue

The Queue is a very important and common Data Structure in Computer Science. As the name queue suggests, this data structure can be described with an analogy of waiting in a line. There is no cutting allowed in the line, so the first person in the line is the first person out of the line. With the data structure it is the same way First In First Out (FIFO).

The best way of managing the data in a queue in my opinion is by storing the data in a "circle" by this I mean that when we reach the end of the contiguous data if we have room at the beginning we can start filling in there. This data is stored kind of like a snake going through a circular pathway. The snake will grow and shrink as it travels along this path.

Methods of a Queue

There are only two functions which are required with a queue. One will insert data into the queue and one will remove data from the queue. (One to grow the snake and one to shrink the snake) We call these two functions Enqueue and Dequeue.

  • Enqueue is our method for adding new items to the queue. It will add the new items to the back of the queue.
  • Dequeue is our method for removing items from the queue. It will remove items from the front of the queue.

Since I like my collections to not be limited in size, we will also have a private function for increasing the size of the queue if we run out of space and need to add another element.

Common Implementations

Generally a queue will be an array and it will have a pointer to the front of the queue and a pointer to the end of the queue. As new items are added and removed the pointers will adjust themselves. The pointer to the end of the queue is the pointer to the location where the next element will be placed into the queue, and the pointer to the front of the queue is the location of the next element which will come out of the queue.

In my example I have simplified this a little bit by not using pointers. I'll just be using a FrontIndex and a BackIndex which are just integers telling me which index to use for my array.

Simple Sample C# Implementation

As I like doing, this queue will be a Generic queue, so this is how it will be defined.

public class Queue<T>
{
}

With the class defined, I'll start by adding the following properties.

#region Properties
 
/// <summary>
/// The capacity of the Elements Collection
/// </summary>
private int _capacity;
public int Capacity
{
    get { return _capacity; }
    set { _capacity = value; }
}
 
/// <summary>
/// The number of elements currently in the queue.
/// </summary>
private int _length;
public int Length
{
    get { return _length; }
    set { _length = value; }
}
 
/// <summary>
/// The actual data elements stored in the queue.
/// </summary>
private T[] _elements;
protected T[] Elements
{
    get { return _elements; }
    set { _elements = value; }
}
 
/// <summary>
/// This is the index where we will dequeue.
/// </summary>
private int _frontIndex;
public int FrontIndex
{
    get { return _frontIndex; }
    set { _frontIndex = value; }
}
 
/// <summary>
/// This is the index where we will next enqueue a value. 
/// It is calculated based on the Front Index, Length, and Capacity
/// </summary>
public int BackIndex
{
    get { return (FrontIndex + Length) % Capacity; }
}
 
#endregion

Once I have these properties in place I'll add my basic constructors; one which takes no parameters and one which takes a capacity.

#region Constructors
 
public Queue()
{
    Elements = new T[Capacity];
}
 
public Queue(int capacity)
{
    Capacity = capacity;
    Elements = new T[Capacity];
}
 
#endregion

Now that I am able to create the queue, it is time to start adding the functionality. As I've mentioned, we need to have enqueue, dequeue, and the private method IncreaseCapacity.

With Enqueue I'll have it take in an element and then check to see if we have space. If we don't I'll increase the capacity, and if we do I'll add the element at the back index and increment the length. Since we are calculating BackIndex based on the FrontIndex and the length we don't have to manually adjust it.

Dequeue will make sure we are not empty and if we are it will throw an error. We then want to pull the next element out of the front of the queue and adjust our length accordingly. We also want to increment our FrontIndex. Notice that we increment it by 1 and mod it by the Capacity. This gives us the remainder of FrontIndex + 1 / Capacity. This gives us our circular storage. It makes it so when we read the end of the array we start back at the beginning.

#region public methods
 
public void Enqueue(T element)
{
    if (this.Length == Capacity)
    {
        IncreaseCapacity();
    }
    Elements[BackIndex] = element;
    Length++;
}
 
public T Dequeue()
{
    if (this.Length < 1)
    {
        throw new InvalidOperationException("Queue is empty");
    }
    T element = Elements[FrontIndex];
    Elements[FrontIndex] = default(T);
    Length--;
    FrontIndex = (FrontIndex + 1) % Capacity;
    return element;
}
 
#endregion

Increasing the capacity is not very difficult. In this example I am going to add 1 and double the capacity when it needs to be increased. I like the idea of hitting a reset button on the queue every time we increase size, so I'll create a new queue and enqueue into it every element from the current queue using the dequeue method to empty the current one. I'll then assign all of the properties of the new queue to the current one and I am done.

#region protected methods
 
protected void IncreaseCapacity()
{
    this.Capacity++;
    this.Capacity *= 2;
    Queue<T> tempQueue = new Queue<T>(this.Capacity);
    while (this.Length > 0)
    {
        tempQueue.Enqueue(this.Dequeue());
    }
    this.Elements = tempQueue.Elements;
    this.Length = tempQueue.Length;
    this.FrontIndex = tempQueue.FrontIndex;
}
 
#endregion

With this function we should now have a working Queue structure. To test it we can run it through some quick little for loops.

Queue<int> myQueue = new Queue<int>();
for (int i = 0; i < 50; i++)
{
    Console.WriteLine("Enqueue: " + i);
    myQueue.Enqueue(i);
    Console.WriteLine("New Length is: " + myQueue.Length);
}
 
for (int i = 0; i < 50; i++)
{
    Console.WriteLine("Dequeue: " + myQueue.Dequeue());
    Console.WriteLine("New Length is: " + myQueue.Length);
}
 
for (int i = 0; i < 50; i++)
{
    Console.WriteLine("Enqueue: " + i);
    myQueue.Enqueue(i);
    Console.WriteLine("New Length is: " + myQueue.Length);
}
 
for (int i = 0; i < 50; i++)
{
    Console.WriteLine("Dequeue: " + myQueue.Dequeue());
    Console.WriteLine("New Length is: " + myQueue.Length);
}
 
try
{
    myQueue.Dequeue();
}
catch (InvalidOperationException ex)
{
    Console.WriteLine("As expected I received this error: " + ex.Message);
}

Once we run that and see that it works we know that we probably have a Queue that works pretty well.

Once again here is the entire Queue Class.

public class Queue<T>
{
    #region Properties
 
    /// <summary>
    /// The capacity of the Elements Collection
    /// </summary>
    private int _capacity;
    public int Capacity
    {
        get { return _capacity; }
        set { _capacity = value; }
    }
 
    /// <summary>
    /// The number of elements currently in the queue.
    /// </summary>
    private int _length;
    public int Length
    {
        get { return _length; }
        set { _length = value; }
    }
 
    /// <summary>
    /// The actual data elements stored in the queue.
    /// </summary>
    private T[] _elements;
    protected T[] Elements
    {
        get { return _elements; }
        set { _elements = value; }
    }
 
    /// <summary>
    /// This is the index where we will dequeue.
    /// </summary>
    private int _frontIndex;
    public int FrontIndex
    {
        get { return _frontIndex; }
        set { _frontIndex = value; }
    }
 
    /// <summary>
    /// This is the index where we will next enqueue a value. 
    /// It is calculated based on the Front Index, Length, and Capacity
    /// </summary>
    public int BackIndex
    {
        get { return (FrontIndex + Length) % Capacity; }
    }
 
    #endregion
 
    #region Constructors
 
    public Queue()
    {
        Elements = new T[Capacity];
    }
 
    public Queue(int capacity)
    {
        Capacity = capacity;
        Elements = new T[Capacity];
    }
 
    #endregion
 
    #region public methods
 
    public void Enqueue(T element)
    {
        if (this.Length == Capacity)
        {
            IncreaseCapacity();
        }
        Elements[BackIndex] = element;
        Length++;
    }
 
    public T Dequeue()
    {
        if (this.Length < 1)
        {
            throw new InvalidOperationException("Queue is empty");
        }
        T element = Elements[FrontIndex];
        Elements[FrontIndex] = default(T);
        Length--;
        FrontIndex = (FrontIndex + 1) % Capacity;
        return element;
    }
 
    #endregion
 
    #region protected methods
 
    protected void IncreaseCapacity()
    {
        this.Capacity++;
        this.Capacity *= 2;
        Queue<T> tempQueue = new Queue<T>(this.Capacity);
        while (this.Length > 0)
        {
            tempQueue.Enqueue(this.Dequeue());
        }
        this.Elements = tempQueue.Elements;
        this.Length = tempQueue.Length;
        this.FrontIndex = tempQueue.FrontIndex;
    }
 
    #endregion
}

Happy Data Structure Building!