As part of this year's Google Summer of Code I have the chance to bring C++2011 support to KDevelop. Yeah, it once was C++0x, but since the new C++ spec reached FDIS status this year and is targeted for a release very soon™ it's officially called C++2011.If you are interested in C++0x/2011 and want to get an overview over the new features, I can recommend to read the Wikipedia article on that topic. I've also started a series of posts on my blog where I try to explain the new features I've added support for in KDevelop.
Anyhow, what do I do all day long when hacking up support for this in KDevelop? First up, I read the spec changes for the new features, as listed e.g. on the GCC C++0x support page or directly in the FDIS spec. Then I dive into the KDevelop code and patch our C++ lexer, parser and/or DUChain builders. Most often this is neither very hard nor complicated work, rather it is pretty time consuming to find the proper places to patch and understand the control flow properly. Thankfully this work is easily unit testable, which makes my life much easier.
Which brings me to the next point: If you are eager to use the new C++ in KDevelop, you probably cannot await a release which brings all this support. Well, rejoice Thankfully C++2011 is backwards compatible and we have enough unit tests to ensure an established level of stability for the changes required to our codebase. Hence I think it's safe to assume that we can expect quite some C++2011 support in the next KDevelop release, which would be version 4.3. We aim at a release in August, lets see.
As I was asked how KDevelop compares to other IDEs in regard to C++2011 support, I have to admit I'm not sure. I know that there are some patches available for QtCreator. Furthermore there is e.g. XCode 4 which uses CLang internally. Considering that the latter has support for quite some C++2011 features, it wouldn't suprise me if XCode 4 does so as well. Still, I think I can safely say that KDevelop will be one of the first IDE's to support the new C++ spec in large parts. Note that I don't (yet?) try to support features that are not yet implemented in GCC 4.6.
Ok, that would be it. Thanks for reading and back to hacking for me!