While I have some relevant experience in a bunch of programming languages (C, C++, C#, Perl, Java, Python), the majority of my time has been spent programming in C++. This has been both a blessing and a curse. C++ as a language is immensely powerful, and I absolutely love it. It allows me to choose the abstraction level I want, from dabbling in the low-level realm of bits and registers, all the way up to template based meta-programming. Some of the things I can do in C++ are unmatched in other languages. And while that is without a doubt partly due to my familiarity with the language compared to others, I cannot help but feel there is something inherently powerful about C++ that makes it possible.
Still, programming in C++ is not without its cost. For starters, at least until C++11 arrived, there were some fairly fundamental areas where C++ was lacking features which more recent languages had built in. Things like threading-support, regular expressions, lambda functions and automatic type deduction are some things that required extra libraries, or were not possible at all. Luckily there were the Boost libraries, which helped a lot in that area.
Another issue with C++ is the rapidly increasing build-times as a project grows in size. Now this is something that you have some degree of control over, as described extensively in John Lakos’ seminal book on the subject, but there is no denying there are some fundamental features of C++ that have a severely detrimental effect on build times. Most conspicuously is of course the #include directive, the preprocessor in general and the choice to split declaration and implementation of a class into a .h and .cpp file. While again powerful tools when used right, #include’s especially are very costly for a compiler to resolve. Build times for even moderately sized C++ projects can easily run into several minutes, even with incremental builds and precompiled headers, with clean build times of many tens of minutes are not unheard of.
Given that there are other languages that are at least close to matching C++’s expressive power, come with expansive, mature class libraries and build in a fraction of the time C++ takes (or have no build times at all, in the case of the interpreted languages), is there a scenario where it still makes sense to choose C++ as a programming language here in 2012?
As it turns out, there is, and the reason is Qt.
Qt is well known in the C++ world as a UI toolkit. Over time, however, Qt has developed into something much more than just a UI toolkit. It also includes containers, smart pointers, threading, a signals-and-slots mechanism and a unit testing framework, amongst many others. The latest versions of Qt have included support for QML, which is a declarative language to build UI’s, somewhat like XAML does for .NET. The very latest version of Qt (As of this writing that is Qt5 Beta 2) includes QML2, and a fully OpenGL accelerated rendering pipeline. The result is nothing short of spectacular, and it makes Qt an incredibly compelling proposition for developing UI’s.
The reason Qt makes C++ relevant in this day and age are its excellent cross-platform capabilities. Qt compiles and runs on pretty much every platform that has a C++ compiler, which is pretty much every platform in existence, and certainly includes the major platforms today. It runs either under a windowing system such as KDE, OSX or Windows, or without a windowing system at all, in which case it falls back on its own.
All of this makes Qt eminently suitable for cross-platform and embedded development, both areas in which Qt blows the competition out of the water.
Many cross-platform applications do not use Qt, but I they invariably suck from a UX perspective. As far as I am concerned, there is no other UI toolkit out there which is so refined when it comes to matching the look and feel of different operating systems. A Qt application looks like a native Windows application when run on Windows and like a native Gnome application when run under Gnome
Perhaps even more interesting are the embedded options. There is a tidal wave of touch-screen devices washing over pretty much every industry out there, from manufacturing to medical to consumer electronics. These products are increasingly running on ARM processors, often with some type of GPU included. Ever since I managed to get Qt5 working on my Raspberry Pi, I’ve been amazed at the performance of the UI. Remember, Qt5 is OpenGL accelerated, and QML2 allows you to embed GLSL shaders directly in your UI, which enables some pretty spectacular UI effects. Check Andrew Baldwin’s awesome video for a demo of the possibilities.
So is C++ still relevant? In my opinion: Yes, for particular contexts. If you are developing a cross-platform desktop application, I don’t think there is anything better than QML/Qt out there at the moment. If you are developing an embedded application that needs to run on a low-power ARM platform with OpenGL, there if definitely nothing better out there than QML/Qt.