Transition from Java to C++ — some insights
In this post I talk about my programming language transition from Java to C++ and my experiences so far.
If you start as a computer science student it’s not uncommen that the first programming language you learn is Java. At least that was the case at my university. Back then, the programming languages I felt comfortable with were Pascal (learned at High School) and Java (university). I soon considered Pascal to be insufficient, though. As a CS student I naturally came in contact with other languages too like Prolog, Lisp, etc. But it wasn’t until after I finished my masters that I started learning C++. That’s because I mainly have to do serious number chrunching and C++ is certainly “closer to the machine” than Java. Also, I didn’t like the idea of abandoning paradigms like OOP with dynamic polymorphism. So, doing “plain C” seemed like a step backwards.
If you want to learn a programming language like C++ it’s a good idea to invest some money in a good and highly regarded book about C++. The free resources on the web just don’t cut it. I certainly didn’t regret buying “TC++PL” (The C++ Programming Language by Bjarne Stroustrup, Special Edition). Trust me, you won’t be disappointed either — unless perhaps you’ve no programming experience whatsoever. The book gently introduces the reader to all the programming language’s features and most of the standard library’s features. I’ve heard of templates and their power before but I was really pleasently surprised to hear about things like RAII, for example.
But during the first few months I learned other important lessons as well:
- You can’t expect to get away with the old programming style in a new language — especially in the case of a transition like Java -> C++.
- It’s not enough to be familiar with the new language’s features. You have to figure out how these features interact and how you can make use of them effectivly.
The difference between C++ and the other languages I knew is really bigger than what I expected.
Old habits like creating objects on the heap and passing around references often prove to be bad design choices at a later stage. You have to think about object “ownership” in C++. What part of your program is responsible for deleting those dynamically allocated objects? We don’t want to have resource leaks! So much to think about. What a bummer, right? Well, this is what I mean by programming style. Once you learned how to effectivly use the language’s features it gets a lot easier. Resources including heap allocated objects can be encapsulated in light-weight objects that have “automatic storage“. RAII takes care of cleaning up. These light-weight objects can be passed by reference or by value, whichever is more appropriate in the specific case. With standard containers like std::vector, the number of ‘new’ and ‘delete’ operator invocations can be reduced to a minimum. Also, many cases where a Java programmer would naturally choose dynamic polymorphism turn out to be solvable via templates. You don’t always need dynamic polymorphism. Template-based generic programming is a form of static polymorphism. It can result in highly performant code. You can even mix dynamic polymorphism with static polymorphism. The relevant idiom that makes this possible is called “type erasure”. C++ is not just “C with classes”. It’s much more than that.
Right now — after one year of C++ experience — I’m (still) fairly happy with C++. It’s not perfect but for my needs it is unmatched. There’s undoubtedly room for improvement. Luckily this is being worked on. The new standard’s working draft includes many compelling features that will make the programmer’s life easier. Just to name a few:
- concepts (similar to Haskell’s type classes) will greatly improve support for generic programming.
- rvalue references for move semantics, perfect forwarding and the ability to distinguish between lvalues and rvalues
- type inference (auto, decltype)
- lambda functions and expressions
- lots of nifty library extensions
– P
Leave a Reply