After a few years of developing only in C# (all my hobby projects, e.g. modding tools, as well as my thesis, were written in C#, targeting .NET 4 and using WPF for the pretty (the what?) UI), I’m “back” to C++. To be brutally honest, I haven’t used C++ much. I did use it for whatever university assignments I had that required it, and I learned some pretty basic and important concepts with it, such as server-client architecture, multi-threading, message passing, parallelism. Only reason I didn’t get into it more was because when I did decide to get in trouble and start developing on a daily basis on projects I loved, I had already discovered C#. C# promised the power of C++, with a minimal amount of the trouble that C++ could cause you. Its power, the level of automation and abstraction the .NET platform offered, and how well tied it was with Visual Studio made it an absolute pleasure of a language to develop in. I could do everything I wanted, I had Visual Studio’s magnificent visual debugger, IntelliSense, documentation, I had LINQ; you could say the world was my oyster. And I created some useful things with it. All my modding tools were put to use by the basketball modding community, and NBA Stats Tracker was even used by a varsity basketball team in the US. I learned a whole fucking lot from using C#. My first big project, the delicateness of code where a single, innocent-looking change can break so many things in the rest of your project, trying to refactor and messing things up, trying to find what went wrong in a stack trace that was 9 calls deep, how to properly design an object-oriented program, what to do when you manage to crash the CLR (yes, that actually happened), so many things that I simply cannot list of the top of my head, really.
But C# is a world of convenience. 50% of what you need to do, it’s there, in the libraries. Memory allocation? Done for you. You declare and allocate everything the same way, not having to worry if something won’t fit in the stack, not having to worry about dangling references, segmentation faults, undefined variables.
For someone that had gotten used to the conveniences C# offered, especially its magic garbage collector (which, mind you, has its downsides, as you have absolutely no idea whatsoever when an object is going to be destroyed; even when the references to it reach 0, it won’t be destroyed and hence, the memory won’t be freed until the garbage collector decides to roll around your memory again and do its job), the prospect of having to use C++ terrified me. However, and this much I can share, after all my applications to US universities for doctoral studies were done, I was approached by two companies from the video game industry. Important note here: I have never applied for a job. Anywhere. I can admit I have only applied to Microsoft for an internship twice. My CV was good enough, my phone interview, apparently, not so much. I know what went wrong there, and each time I focused to overcome my shortcomings. I truly believe I’m in a much better place now.
So, back on the subject. These companies are flying me over to the US to interview me. Which is great. And terrifying. And exciting. And then some more of everything I just said. And from the little I know about the gaming industry, they needed to work with the 360 and the PS3. Which means that even the greatest console games up to today had to limit themselves to 512MB of RAM. Ouch. So, it’s no secret that most of the core gaming code that’s ever been written is written in C++. There’s obviously scripting languages involved (Lua is pretty popular), and of course you have to code the AI (which, if my university’s subjects about it taught me anything, is to praise the people that go through that ordeal to no end). But, C++ is the one requirement you’re going to see the most in the “software developer” and “software engineer” job listings in the industry. A good reason for that is that it’s as powerful as C (allowing you to go as low-level as you’d like), it allows you to do OOP, it has great libraries, and it allows you to do your own, strict memory management. (On why not C#, you can read a good article here, which goes beyond the obvious “JIT vs pre-compiling” and “automated garbage collection vs manual memory management”.) Game engines have been written in C++ for years. Most, if not all of the codebase, is in C++. Unless you’re working on a new project that can just decide to use another language, or you’re willing to port and re-write a lot of the pre-existing code, you’re going to need to know C++. And “some university assignments” as far as experience goes ain’t going to cut it.
Granted, I feel lucky. To tout my own horn a bit more (it’s my blog, what did you expect, self loathing?), whenever I picked up a new language, it didn’t take long before I got accustomed to it. I truly believe that if you’re good in coding, you can easily be competent in any language you put the effort into. The challenge is gaining enough experience, and then mastering it. Back during the Natural Language Processing course, we were assigned a project where we had to make a basic web crawler, download and index any pages that we could find that had more than 100KB of good data up to a certain amount (1000 pages, if I remember correctly), and make a search engine out of it. There was no strict requirement on which language to use, but the course was a NLP course by day, Python course by night. So it was recommended to us that we dabble our feet in the waters of Python, see if we like it or not. Who am I to say no to a new challenge? I knew colleagues who loved Python to no end (@dimle, I’m looking at you), so I got curious. I had no experience in Python whatsoever, yet after putting two 10-hour shifts, the project was already done. In pretty, fully documented Python. It felt so good for so many different reasons, and Python became my favorite language for basic scripts and small tools.
I knew, then, that I could tackle any programming language that peaked my interest. And that’s how I knew that my OOP background and experience with C# was going to help me tackle C++ as well, since that was an absolute requirement for the positions that were open.
So, why didn’t I apply? I had no idea that such big companies (who shall remain unnamed for now) were interested in developers fresh out of University, with no “official” (i.e. under an employer, part of a serious, tie-wearing company) experience whatsoever; I had no idea they were interested in freelance developers by passion and hobby. Turns out I was checking their job listings at the wrong time. They’re both looking for people like me (and possibly you!), as long as they have the proper C++ experience.
So, now that I know what’s required of me language-wise, my “dropping dead and taking a break until whatever’s next in my life starts” has been put on hold.
Step 1: I got reacquainted with C and C++ quickly by watching Lynda.com’s tutorials on them. The latest edition of the video material even covered C++11 and some of the great things that it offers, which, trust me, are immensely helpful for someone coming from C# 4.0 to C++.
Step 2: I read every single word (well, almost) of “Effective C++” by Scott Meyers. It’s one of the greatest books I’ve ever read, to be honest. Straight-forward, good examples, detailed, well-written. It’s not a tutorial for beginners by any means, but it teaches you effective ways to code in C++, how to use its tricks and how to avoid common mistakes, as well as common misunderstandings and hard-to-diagnose, yet common, errors.
Step 3: Code. I’m working my way through problems of all kinds, from the simplest to the hardest, coding in C++. I’m being memory-efficient (not using additional buffers unless I really need to, for example), I’m trying to avoid unneeded time and space complexity. Yet, the tricks I’ve learned from both the above steps, have not only helped demystify C++ for me, but have also helped me conquer so many of the fears that have been keeping me away from it. I’m no longer afraid of memory management, because I know how to use smart pointers (shared_ptr <3), and I know a lot of the common mistakes that lead to memory leaks. I’m no longer afraid of pointers, because I know about references. And most importantly, I’m no longer afraid of any of what I was afraid before, because I’m tackling each and every issue by actually coding. I’m putting everything I’ve learned both through my programming experience and from reading up on C++ into actual code that does things, that breaks and that I then fix and learn from my mistakes. And you know what? I actually like C++ already.
I know something’s bound to go wrong sooner or later. Some memory’s going to leak, some reference is going to be left dangling, some object is going to be half-destroyed, some buffer is going to overflow, and I will be looking for the damn root of the segmentation fault all night. But I really feel I’m approaching this the right way. I have the programming experience, I know how to go about debugging, I did the proper studying before I started coding, and I have a lot of tricks up my sleeve for whenever the compiler decides to throw that yet another obscure meaningless error at me, or whenever my program starts failing.
I’m getting used to C++’s intricacies. I’m terrified and excited. Same mixture of feelings that I have about my big trip to the US for the interviews, with some salt and pepper on top. But I know I need to show up prepared, and I need to show that I know how to code in C++, that I know how to attack any problem that’s thrown at me with a good mixture of classes, a good algorithm or two, and some of the useful tricks that the latest standard library and STL offer. It’s less than 2 weeks until April 3rd, and I’m going to do my best.
So, C++, it’s you and me now. Let’s dance.