Brendan Enrick

Daily Software Development

C# Generics vs C++ Templates

I regularly meet with a group of my college friends with whom I studied Computer Science. While at a great local bar we have plenty of interesting computer-related conversations. A lot of .NET developers probably spend most of their time discussing technical topics with other .NET developers. Our conversations are much more interesting because everyone there works with different languages and different types of technology. It really adds a lot to our discussions. So as has happened a few times, I mentioned C# Generics. As usual it sparked a conversation about how C# Generics are not as good as C++ Templates. As usual I agree with them. (Yes, I really do like C++ templates better than I like Generics in C#)

So I searched on MSDN, because I wanted to see what Microsoft cites as the key differences between C++ templates and C# Generics. I found this article explaining the differences between C++ templates and C# Generics. OK, I agree these are some important differences. It says on there specifically that they were not even trying to have as much functionality as templates. It is good that they said that, because the list of "differences" could be renamed "reasons why templates are better".

The list of reasons cites a bunch of differences in how they are able to be used. I still want to know the differences in the implementation of them. For that big important difference they have it separated from the nice list. Its in the paragraph of description. They mention one HUGE difference. As they say, "C# generic type substitutions are performed at runtime and generic type information is thereby preserved for instantiated objects." So what is the big deal you might say. There are good things and bad things here for generics.

Since templates are compiled at runtime, the compiler will figure out every version of the template it needs and will create the code for them. This is great because it gives optimal performance. Sure there is a bit more code, but it is nice to not have to create these methods at runtime. With C# Generics, the required code is created at runtime. Ok so that sounds pretty bad. It isn't really as bad as it sounds. Generics are implemented smartly, and because of this it isn't much of a performance issue. So at runtime our code will be created to handle the different types our generic can handle. What if we're going to have a bunch of types? If they're all value types then you could have a problem. It will actually create a completely new implementation of your code for every value type you use for the generic. If you're using a reference type it uses some cool tricks to point to the correct type, so it only has to have one reference type implementation. This means you'll have the performance hit once when you first need the generic on a reference type. Then it is a minimal hit each other time you need it.

Yes, I was a C++ programmer before I learned C#. I hope you enjoyed this post. I appreciate comments. I really like the ones which add something to the post, so if you've got extra information to add I encourage you do so. If I've made any mistakes in this, please let me know.

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.