Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

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.

Monday, November 17, 2008

Realmware

So I know it's been a while since my last entry, but I've been rather busy. I'm still working on some C++ work, but the most of my time has been going to learning C#. The project I'm working on switched engines again. Instead of using Unreal now, we're using Visual3D.NET. It's a new game engine being developed by a company called Realmware. Realmware visited UAT a couple weeks ago for our Tech Forum event. As it turns out, Realmware's engine was one of the engines our team was seriously considering using after we had to drop CryEngine2 because of German laws. Turns out they were coming to speak at our school. We were able to set up a meeting with their CTO, Brian Knox through Nate.

So as it turns out, they were impressed with our team and concept and we proposed a deal with them to work on their engine and pretty much partner with them so they have something (our game) to show off what their engine can do. We benefit by not having to pay for commercial licenses for the engine. Since the engine was written in C# and as a lead, I'm going to be working on engine code, I've been spending time learning more C#. Unfortunately, most of my programming skill is in C++. I've taken 2 classes where I've had to use C# (Managed DirectX, and XNA), but never a formal class on it. I am taking C# I next semester, but I need to get a jump start anyway.

With all of this going on, it's been pretty busy. It's only going to get much worse from here on out, though. Once me and the other programmers get into full swing, we should be programming around 50 hours per week. We're hoping to have most of the engine stuff we need to work on to get our game to work with the engine done by Jan 1st. While 3 of us work on that, the other 3 programmers on the team will be working with the rest of the group on a smaller project that can be finished by the time we're done with our engine stuff. By then, we can get started on our main project - which is the reason we started this in the first place. The good news out of this is that I've got an internship through Realmware now. So after next semester, I'm officially done at UAT. That's why I'm trying to get as much practical experience programming as I can now.

That's about all I have time to post about for now. Hopefully my next post won't wait as long as this one did. Until next time...