I love C#. I really, really, really love C#. I got into the language because I wanted to develop for what then XBox Live Community Games (now known as XBox Live Indie Games), and Microsoft’s C# library XNA was the only way to do that. Once I got the general hang of it, using C# was the first time since fiddling around with QBasic as a kid that I actually enjoyed programming. I rarely felt like I had to “fight” the language to get things done, the way I usually do when working with C++. Sure, the language has its faults and quirks, and the lack of control over the garbage collector can be more than a little annoying, but it really is an all-around magnificent language to work in and so I love it to death.
However, the current state of support for the language is a bit irksome to me. Another Star was coded completely in C#, built on top of a custom engine that interfaces with system APIs by way of a library called OpenTK. OpenTK always annoyed me a little, often depreciating entire sections of the library before the parts meant to replace it were even implemented, let alone completed.
Just as Another Star was heading to release, a new major version of OpenTK finally came out, and it changed up the way a lot of the engine’s user input worked (keyboard, mice, gamepads, etc.). Trying to “correctly” implement these new designs has proven frustrating, as things I relied on have been removed without any real replacement. Some of these changes even led directly to bugs in Another Star; especially the Linux version. Bugs in the library also make it really difficult when trying to fix things, because I can never tell for sure whether something isn’t working because of my code or someone else’s. Or, for that matter, if I can even fix it.
I knew, even before working on Another Star, that I would probably have to move to another C# library in the future. I continued to look for a suitable replacement, but never really found anything I liked. The closest I got was a C# wrapper around the widely used C/C++ library SDL2, but it was little more than that: a wrapper. The syntax is pretty much just straight up C, without any attempt to translate it to C# conventions, at which point I feel like I might as well just code directly in C++.
So I finally gave up and that’s exactly what I’ve been doing. The past month or so, I’ve been hammering out the beginning of a game in C++, the programming language that I’ve always had a loathing for (and, at times, outright hate). C++ is nearly forty years old at this point, and in that time has accumulated a lot of cruft. It’s gotten a lot of updates over the years to keep it relevant, with varying success, which has made it—at least, in my opinion—very ugly language, especially to look at.
But the fact of the matter is that virtually all the important API libraries are written in C++. If I don’t want to build my game on top of somebody else’s code, this is my only recourse.
I already regret my decision.
I actually like C++ the most. At work I’m using C++ and I made several games with C++.
Our company actually slowly migrates to C# so I’ll have to learn that too. The code right now looks really unreadable to me because so many things are done in very little lines of codes, but I guess in the long run C# is better… I hope. ^^;
I’m also working on an open source project that is written in C and man… that really makes me miss C++. Just writing some text into a variable sometimes took me hours in C. Ugh.
One I the things I can’t stand about C++ is that, being a language from the late 70s and early 80s, it’s still tied at the hip to header files. It’s also absurdly verbose just to do simple things.
For example, to do a proper accessor in C++, you need all this in your header:
class Example {private:
/* The private variable. */
int something_;
public:
/* Getter.
* Explain what it does here. */
int something() const;
/* Setter.
* Explain what it does here again,
* maybe in more detail this time. */
void setSomething(int);
};
And then, in your code file, you have to actually implement them.
int Example::something(){
return something_;
}
void Example::setSomething(int something)
{
something_ = something;
}
I mean, you can do it all directly in the header, but I don’t like mixing my definitions with my implementations. Unless they’re a template, and then you have to do it in the header, but I usually avoid templates like the plague whenever possible.
And, of course, there’s usually quite a few accessors for larger classes, so I spend a lot of time just doing boilerplate stuff like that.
Now, compare that to C# like so:
public class Example {///
///
public int Something {get; set;}
}
Boom. I’m done.
I can even take it a step further with a single word.
public class Example {///
///
public int Something {get; private set;}
}
Now other classes can get Something, but only the Example class can set it. Real time saver.
One of the big pitfalls of working in a language like Java or C# is that they look so much like C++ that it’s misleading. You can write the same thing in one language as another, and it’ll be legal and compile, but it won’t work the way you think it does because of the actual differences between them.
That caught me off-guard moving to C# at first, and it’s done it again as I go back to C++.
I wouldn’t say C# is “better” per se, although it’s definitely better at certain things. For one, I don’t miss the garbage collector. (Although the process of allocating memory in C++ actually leads to the exact same pitfalls, I’m slowly finding out.)
And… HTML ate all my carefully formatted code. *sigh*
That example. =D
In C++ if I just had a variable I want to access from the outside anyway, I’d just write it as a public variable in the class and then just access it with object->variable.
That’s pretty much the same as in the C# code. Both one line basically.
Even if I make it a property with get/set methods, for me it seems much easier to understand because I can see what the get/set methods actually do. I can easily make it so that the “get” method actually works differently than the set method. Like when I know all the write-access is done at spots where I have a string, but all the read-access requires an int. I could make the set method so that you can give it a string and convert it to int before writing it to the variable, so I don’t need to do the conversion at every point I access it.
But well probably you can do something like that in C# too.
As for no header… well I find header is annoying to write but nice to read. If header would just be automatically written while I write the C++ code, that would be cool. Since header allows me to easily check all the variables and methods a class offers.
Of course with modern tools those lists are auto-generated for you anyway, but I rather read a header file than for example clicking on that Visual Studio combo box that when expanded shows me all the methods of the file.
For me it’s also a matter of sorting! In my C++ I always made sure the header file shows every method in the order I implemented it in the cpp file. Then I can easier check how to rearrange them so related ones are closer together so that I can debug faster (by just using the mouse wheel rather than searching for the function that is called).
Thosea re probably just things you need to get used to, though.