C++11 support in Qt 5

Marc Mutz posted today a blog calling for immediate support of C++11 in C++-based projects. He also linked to Herb Sutter’s blog saying the standard was unanimously approved in the ISO voting. In his blog, Marc calls for Qt 5 and KDE 5 to require C++11 in the compilers.

I agree with the principle and I’d love to take up on what he’s asking for. But it’s unrealistic for Qt 5.0. Requiring C++11 will take at least one or two more years, when compiler support is a little more widespread. For KDE 5 (or KDE Frameworks), support may come sooner, as the need to support older compilers is smaller.

That said, last month I posted an update to the qt5-feedback mailing list a proposal to update Qt’s use of STL. In particular, I called for the decoupling of the language features from the use of the C++ standard library, putting the emphasis on the embedded systems and cross-compiler compatibility.

I also proposed completely dropping support for compilers that don’t support C++98, especially support for pre-C++98 STL. Of course, we have to be pragmatic, as even in 2011 some mainstream and widely-used C++ compilers fail to support certain advanced C++98 features like template-template parameters (not supported on Sun CC last I checked) or template friends (no support outside of GCC). And, of course, there are compiler bugs or shortcomings we sometimes have no choice but to work around.

STL cannot be used in Qt’s API in a way that it changes the binary compatibility guarantees, but it can be used with Qt as well as used internally. For example, it’s fine to have template code in QVector that supports std::vector and it’s fine to use std::thread (C++11) internally. My submission for the new atomic classes even uses std::atomic where it’s available.

When it comes to C++11 support, I proposed using it to provide access to new / advanced functionality, provided it still respected the limitations above (cannot affect binary compatibility). That is, if you have a C++11 compiler, you’ll get more features, but not having it will not impede your use of Qt. And you’ll be using the same Qt build that someone with an older compiler uses. At least, for the time being.

One feature I’d like to see supported only in C++11 is the new signal-slot connection syntax. C++11 allows us to properly write perfect-forwarding of an arbitrary number of parameters, whereas C++98 requires putting an upper limit on the parameter count and jumping through hoops for those few. Trust me, I’ve done the research and you can read the works of others who have tried to do perfect forwarding in C++98.

If we can find a couple more such interesting features, our users will start using C++11 and start requiring those features from their compiler vendors. In summary, I don’t think we can mandate C++11 just yet, but we can make it attractive enough that people will want it. So let’s not be afraid of C++11, let’s drive its adoption!