Well, I wanted to start off by mentioning a few things. First of all, in case you hadn't noticed, quotes changed a bit! This is actually a side effect of another change that is taking place, specifically in how I am going to deal with the code in my journal. This isn't going to be a big change really, mostly format wise. I find that having text, followed by code, then followed by more text to be rather disruptive when trying to read an article or other resource. So, I've opted to adjust my formatting so that code will now appear on the right, with the text wrapping around it. A format that I feel will give a much cleaner look, and make it easier to follow.
Secondly, thanks to those of you who actually commented [grin]. Journals should be, in my opinion, a place for you to express your concerns, thoughts, and knowledge freely. At least, that's how I feel. In my case, I've decided to take to the latter, with only minor incursions into the other two. But sometimes you see things that just make you want to comment, however you resist the urge, either because it's not appropriate at that point in time, or because you haven't fully digested what you've seen. In my case this comes from the STL and newbies thread (ineptly named, considering that name is defunct, but oh well). Now, I've spoken with a lot of people, and most of those with whom I hold a high standing of agree with me on this topic, but not all do. The basic premis of our agreement is that learning the standard library from the start is a good thing. It's not so much that it means you don't know how pointers and stuff work, it's that you get off the ground and running faster. Yes, you will learn pointers, you should learn pointers, and you should learn how to deal with memory management on your own. You should also learn how those delicious data structures work. But, when a newbie is just beginning, there is no reason for that knowledge. They want to get off the ground and running, not be stuck in the quagmire that is low level C++. Yes, it is low level, and no, you will not use pointer manipulation unless you're doing programming on a limited platform or thinking you can "out optimize your compiler." This is why we get newbies who claim to know C++, begin writing their game, and come running back when they can't figure out how to store a dynamic number of objects, they have given up on actually learning the language and moved on to just writing code with no direction or guidance. This is why when asked: "Did you debug it?" I get a variety of responses, most of them dealing with logging. Logging is not debugging. You have an integrated debugger, even GCC has that, learn to use it. But if you use the STL, you won't have to use that debugger as much.

I also see a lot of language wars... why? Do you not realize that for you to be of any worth to the industry you will need to learn a myriad of languages? Seriously, C++ is not the end all be all of languages. You will encounter so many languages out there, that focusing on only a single language to the exception of all others is just plain stupid. Yes, as a newbie you should focus on a single language, that you might master it better, but remember, a language is just a tool. It's the concepts behind the language that you should be learning. So instead of posting a thread saying: "C++ vs C#" and then arguing over speed and other issues, which you will NEVER reach because you are a n00b and thus do not have the experience to be able to push a machine to it's limits, pick which ever one seems to fit you better. In fact, I wouldn't recommend starting with either, but with a simpler language, one that will introduce you to the basic concepts of programming. Basic comes to mind, so does Python. That's right, learn basic or python. Get the syntax down, but more importantly, get the concepts down. As far as C++ vs C#... learn them both. In fact, learn every language you can, all the way down to FORTRAN. Sure, you'll probably never encounter fortran unless you go work for IBM, but it gives you yet another way of thinking about how to solve a problem. Programming is about solving problems, not about your pretty language that you love to extol.

[Test]public void GetIdFromTypeTest() {	NetworkFormatter formatter = GetFormatter();	Dictionary typeIdMap = formatter.GetTypeIdMap();	int id = typeIdMap[typeof(SerializableObject)];	Assert.IsTrue(id == 0, "Expected the ID of SerializableObject to be 0, found {0}", id);}

Now, as far as that new format goes, I'll bet you're wondering eh? Well, here's a sample. As you recall last time I was talking about some refactorings that needed to be done. Well, one of them deals with our GetIdFromTypeTest() method. Specifically, the statement typeIdMap[typeof(SerializableObject)], this really belongs in the NetworkFormatter class.

internal int GetIdFromType(Type t) {	return typeIdMap[t];}

So, we should add a method to the NetworkFormatter class, called GetIdFromType(). This new method will do exactly what that line of code does, except is queries the Dictionary member of the class. Then we should refactor the test to call this new method. This will also eliminate our need to query for the dictionary in our test method.

Quote:

[Test]public void GetIdFromTypeTest() {	NetworkFormatter formatter = GetFormatter();	int id = formatter.GetIdFromType(typeof(SerializableObject));	Assert.IsTrue(id == 0, "Expected the ID of SerializableObject to be 0, found {0}", id);}