As the C++ programming language prepares to begin its fourth decade (Stroustrup apparently first called it "C++" in 1983), it continues to slowly stabilize.
For one thing, compilers are starting to support significant subsets of the recently standardized "C++ 11" version of the language, as these notes from David Simmons describe. Another good source of such information is this page from Scott Meyers: Summary of C++11 Feature Availability in gcc and MSVC.
Of course, it's more than just the language and its compilers; you have to have a complete "ecosystem" in order to have a complete programming language. Over at the Google Testing Blog, Zhanyong Wan describes the various reasons why Google decided to build their own C++ unit testing framework: Why Are There So Many C++ Testing Frameworks?
You might wonder, when a language like Java was able to reach this level of maturity in half the time, why is C++ still struggling with these sorts of issues after more than 30 years of development? As the Google team point out, the comparison is somewhat unfair, since Java was in some ways created as a response to exactly this question:
Unlike Java, which has the famous slogan "Write once, run anywhere," C++ code is being written in a much more diverse environment. Due to the complexity of the language and the need to do low-level tasks, compatibility between different C++ compilers and even different versions of the same compiler is poor. There is a C++ standard, but it's not well supported by compiler vendors. For many tasks you have to rely on unportable extensions or platform-specific functionality. This makes it hard to write a reasonably complex system that can be built using many different compilers and works on many platforms.
And as the Google team point out, it's fundamentally much easier to write a testing framework for Java than for C++, for a variety of reasons, including:
Another reason is that some limitations of C++ make it impossible to implement certain features really well, and different people chose different ways to workaround the limitations. One notable example is that C++ is a statically-typed language and doesn't support reflection. Most Java testing frameworks use reflection to automatically discover tests you've written such that you don't have to register them one-by-one. This is a good thing as manually registering tests is tedious and you can easily write a test and forget to register it. Since C++ has no reflection, we have to do it differently.
I regularly write in both Java and C++. It is vastly easier to write in Java, but with care I can be quite productive in C++. Tools like testing harnesses and high quality compilers are a big part of whatever language ecosystem you're part of, so it's good to see that the C++ versions continue to move along, however slowly.
I mean, after all, it could be worse: apparently, the second most popular programming language in Japan is COBOL!!
0 comments:
Post a Comment