Now that the new version of C++, C++11 is out in the wild as an ISO C++ Standard, there’s a renewed focus on getting applications, tools, and books up to date with the new standard. The leaders of the ISO Committee have weighed in on the latest versions of the language. There’s Herb Sutter writing about C++11, there’s Bjarne Stroustrup’s C++11 FAQ, and the upcoming C++Now! conference that’s going to be held in Aspen Colorado. Clang is racing to get C++11 support into the stable release of the compiler, and GCC is humming along nicely with it as is Microsoft’s Visual C++. Instead of write about any specific things, I would lend my opinion on what needs to be the new focus not for C++11 the language, but the supporting toolchains surrounding this new language – and the version that’s coming after this one.
With these in mind, I think C++ has to evolve into a direction that makes simple things easy and hard things possible. There was a time that C++ was the language of choice because much of the infrastructure that’s available now was not available then – you kinda had to write your own tools back in the day, and C++ was the easier programming language to use for large systems. Unfortunately now, even with the new features that makes it easier to write programs in C++ using the new modern style, a big percentage of the programs still turn out to be either glue code or repetitive boilerplate. If you’re writing asynchronous systems, they’re made easy with lambda’s, efficient containers, consistent memory model, and concurrency primitives (or at least standard libraries) but you end up with a lot of boilerplate because there aren’t any sane standard HTTP implementations – interfacing with C libraries will be a lot more painful with C++11 considering how much of the C++ standard defines things outside of the C standard’s scope. C++11 is awesome if you’re starting from scratch but when you get to the part where you have to tie libraries together, C++ is still an expert’s language.
I’m hinting at two things here that C++ should address in my opinion going forward: a standardized way of defining modules for easier composition and higher level standard libraries with reference implementations. Let’s tackle each in order here.
First, standardized modules. The reason programming languages like Go, Haskell, and Erlang are getting traction for back-end programming (in the case of Erlang, it’s not really a “systems programming” language unlike Go and Haskell) is because it has a simple and standardized module mechanism. Packaging code in modules that can be programmed against (ala Pascal Units) in terms of interfaces makes modular development really easy. Right now all the module implementations in C++ are vestiges to how the linkers are implemented and implementation specific. There’s a lot of details here that’s worth fleshing out at a later time (there’s a lot of content for the blog) but needless to say it should be simple to import modules into a compilation unit for later linkage – and this should be made standard across implementations.
One of the problems that standardized modules will solve is that of the definition and implementation of the standard library. The STL is awesome as it is at the moment, but it can be a lot more awesome if there’s a defined module layout that will be the same across all platforms and that people can implement shrink-wrapped modules that play well with many other modules in a non-conflicting manner. C++ already has namespaces and it’s a mechanical manner of tying namespaces to modules. Extending a module should then be a matter of dependency and linkage. Without going much into details, C++ needs to solve the problem of coupling. Many things need to be thought out, like how the runtime environment deals with types and namespaces and how linkage and application binary interfaces can be made consistent without sacrificing performance.
The second thing that does need attention is that runtime environment. I’m not just talking about garbage collection and I’m not talking about having a virtual machine. What I’m talking about is the management of runtime elements, things like memory, I/O, concurrency, among other things. Although it is not impossible to write OS kernels in C++, the C++ runtime is mostly still the C runtime (i.e. too limited) to make things like a global optimizing allocation mechanism, thread scheduling, implementing co-routines, and magical things that makes systems programming interesting very painful to do. A standardized runtime environment can make writing stand-alone systems in C++ easier and less reliant on the C runtime. This can also finally solve things like module initialization (when dynamically loading things), static initialization, memory management, and even reflection and runtime introspection features that can be implemented in a standard manner.
The runtime should be as programmable as the Lisp environments, as minimalistic as the Lua runtime, and as performance-sensitive as the C runtime. It should also be as open-ended as possible, still allowing for implementation-specific extensions but defining a standard core that others can build upon. There are a lot of things to flesh out in this idea but it’s something that needs to happen to make C++ a language that’s as viable for systems programming as well as application development with all the goodness of the dynamic languages and the safety of static languages. Short of defining a virtual machine, a standard runtime implementation should definitely be considered for the next version of C++. I don’t like virtual machines as much as the next person but having a well-defined runtime environment will make systems programming a lot less hack-laden as it currently is.
With these in mind I’m putting some effort into writing up papers to that effect so that hopefully these ideas get at least thought about in the next ISO C++ Standards Committee meeting in Kona Hawaii. Hopefully I can get comments and ideas and a discussion going with esteemed colleagues and users from around the world who might have an interest in joining an effort to make this a reality. Let’s make C++ even better by bringing good ideas from other programming languages into C++ without sacrificing the performance and flexibility afforded by our favorite programming language.
Along with this effort I’m going to work on getting the C++ Network Library reviewed for inclusion into Boost and hopefully be a reference implementation for a high-level network library to be made part of the C++ standard. I think it’s about time that C++ gets modern programming features and Web-aware libraries part of the standard to make it more attractive to developers who might want to develop high performance solutions in C++ for the Internet. I’ll be supporting the standardization of the Asynchronous I/O library that’s already part of Boost so that it can be the standard way of programming asynchronous I/O in C++ and made available to more people who do use C++ for network programming.
It’s an exciting time ahead for C++ and I fully intend to help influence that future too.