C++ going forward (2015)
These days some amazing things happen in the world of C++. C remains the dominant programming language used around the world, a much simpler and a language that’s a lot easier to create a compiler for; at the same time, there is a much simpler language trying to break free from C++, and that language was what the big guys from the CPPCon tried to identify these days.
They created a huge set of guidelines (not rules, but guidelines) on how to write your code in C++ so that you can write safe, maintainable code easy and fast. Of course, that’s not how Bjarne Stroustrup puts it, but that’s the main idea.
C++ is indeed changing – is finally evolving towards a language that can do a lot with a lot less. But it’s not there yet – the past few days showed me that things are quite slow to develop and hard to use. Eventually I had to drop to a C library to do some stuff, and while people call this “a good thing”™, I really think it shows one of the places where C++ doesn’t really excel.
Basically, there is no common framework that you can rely on. POCO contains tons of great stuff, but it uses the C++ standard string, and that string class is counter-intuitive – it’s not as nice to use as the QString. And, of course, nobody has the support for various stuff that Boost has (for example an UUID), and when you think about the fact that none of these can actually help you write a WCF client, and you realize you need to resort to something like gSOAP, your project will suddenly get itself clogged with dependencies, and dependencies tend to drag you down. If you want to add an UI POCO will not be enough again, and you’ll have to resort to Qt. Or WTL, or GTKmm, or wxWidgets or…
Yes, there’s the same complaint that I have about Linux systems as well – they really want to offer ten types of somethings. You don’t really need this sort of choice – and it’s really counterproductive, especially for a project that needs to get kicked off and fast. But, as always, after a short while, using any toolkit and any framework becomes as counterproductive in both managed and unmanaged languages. If you can survive the initial slowness, you can go for C++.
I think what Bjarne and the rest of ISO C++ committee tries to do is interesting. I still hope for that simpler language to come out of the shell, and to have a simplified language that is efficient and safe. Reinventing the wheel is underestimated, the wheel can be done better a second time around. Sometimes it’s simply a better choice to just trash all the work that has been done until now and start again.
But C++ goes on. The guidelines (and I’m looking forward to the recordings of the CPPCon conferences) can help a lot to improve the image of the language, as well as the usage numbers. Let’s wait and see, I’d say.