Tuesday, March 10, 2009

C# Delegates

I posted about C++'s function pointers a few posts back. They're pretty nifty, even though my experience with them is pretty limited. I recently learned about something called delegates in C#. They're sort of like C++'s function pointers, but more "safe". They allow you to (like C++'s function pointers) to pass a method to another method for later execution.

It pretty much works like this: You first declare your delegate for use. How you declare it depends on the type of methods you want it to be able to handle. If you wanted it to handle methods with the return type of void and that take one int, you would do this:

public delegate void MyDel(int val);

This creates a delegate that accepts methods of that same signature. After this, you're going to need a method declared somewhere that meets these parameters for it to use. Here's a short example:

public static void DelMethod(int i)
{
System.Console.WriteLine(i);
}

To use your delegate, you first have to assign the method you want it to hold, then call it somewhere.

MyDel handler = DelMethod;
handler(42);

The above code creates a custom delegate using the signature we declared above and sets it equal to the method we created. Then the next line uses the delegate to run the method stored in it and passes the number 42. The output to a console app would just be "42".

Another nice thing about delegates is that they can be added together. If I have three delegates (two with methods stored in them and one new one), I could set the third one equal to the first two added together and when I used the third delegate, it would execute both methods now stored in that delegate in the order they were stored in it.

I'm just starting to learn about this subject, but so far C++'s function pointers make more sense to me. I didn't have to scratch my head as much when learning them. That's not to say delegates aren't useful...they definitely are. It's just taking me longer to understand them fully than it did to learn C++'s function pointers. There are definitely many uses for delegates, but that'll have to be for another post. I just wanted to post about this while it was still fresh in my mind.

Thursday, February 12, 2009

C# and Such

So I'm taking a C# class this semester since most of my programming experience is C++. I thought it would be a good idea to take a formal class on it (as a compliment to learning a bunch on my own because of my internship). Well, the class has turned out to be kind of a joke. I've been learning, but what I've learned has been outside of class on my own time or through discovery with problems out of the book. The teacher isn't the best I've had at UAT. I'm hoping it'll get better as the semester goes along, but at this point, I'm not so sure. It's a 200 level class and the first two things we learned in class were "what is the internet?" and "what is a computer?". It's week 5 and we're learning what comments are and that there are two types of comments in C#.

Oh well. I'm learning more through real world experience than I am in the class, but it would have been nice to have a worth while class. My only problem with C# is that it keeps you too safe sometimes. I find myself falling back into C++ habits and getting frustrated when I get compiler errors for things that worked without so much as a warning in C++. I guess that's part of learning a new language, but right now, I don't feel like I can write in C# as efficiently as I should be able to. There are some features that aren't in C++ in C# that are time savers and all around interesting features. I guess that's more of a plus for the .NET framework, not C#, but the point still remains.

One feature in C# that I'm not 100% sure on yet is Properties. For those who don't know, they're used in classes when you have private member variables. In C++, you'd have to create two separate functions to access private data (one setter and one getter). In C#, you can do that, or you can create a property. It's declared like so:

public int SometimeSimilarToYourVariableName
{
get
{
return _varName;
}

set
{
_varName = value;
}
}

The property takes care of the set and get for you. You can declare both, none, or just one for your private data. Then you use the property like it was a member variable. Code might be something like int foo = object.SometimeSimilarToYourVariableName;. This automatically calls the get portion of the property. It's pretty smart, honestly. At the same time, it's more that it does automatically for you and while it's a really clever feature, I'm not sure about it yet. I can see it being confusing occasionally because for it to make sense, you want the property name to be similar to your private data member's name. In C++ with my dedicated functions, I would never mistake what I was doing because it was an explicit function call, not treating something like it IS the private data.

I came across an interesting article earlier today about this very feature. Someone ported it over to C++. I didn't read through the whole thing, but it's really cool that someone was able to get this kind of C# feature into C++. Regardless of whether or not it's used, it's nice to have the choice, I think.