I finally want to write a bit about my work on KDevelop during this year’s GSOC. To make things a bit more interesting for the whole crowd, even for those heretics that don’t use KDevelop, I want to highlight some C++2011 features I got to know in the process. Hence this multipart blog post should be interesting for all KDE hackers, as eventually we will be able to use these shiny new features of what is to be known as C++2011.

So, lets get down to business. Following is a not-complete list of C++2011 features I’ve already implemented in KDevelop. If I mess something up in explaining a new feature, or if I forget an important aspect, please add a comment.

Range-Based for

This neat little addition is not so important to most Qt developers. We know and love our foreach macro. C++2011 comes with a similar built-in construct called range-based for. Essentially the syntax goes like this:

It’s neat, and very similar in syntax to the oldschool foreach macro. But there is a big difference: Where foreach makes a copy of the container, range-based for does not. This has mainly two implications:

foreach is slow when used with containers that don’t use implicit sharing, most prominently STL containers

range-based for has undefined behavior when you change the list you iterate over inside the loop.

Personally, I think I’ll stick to the foreach macro as it’s known to work well and has no big downsides in most Qt-based applications, as implicit-sharing is widely used throughout Qt.

RValue References / Move Support

This feature is a more advanced topic and mainly interesting for library developers who want to implement move semantics and/or achieve perfect forwarding, resulting in much better performance under certain conditions. Take a look at the Brief Introduction to RValue References, or the associated spec changes. From the syntax POV it’s just a matter of using && for rvalue references compared to the single & for normal lvalue references.

Defaulted and Deleted functions

This addition to the C++ spec is very welcome to me as it makes some code much more readable and also can be used to prevent hard-to-debug bugs or to improve performance. I’m talking about defaulted and deleted functions. E.g. from the wikipedia article:

struct NonCopyable {

NonCopyable & operator=(const NonCopyable&)=delete;

NonCopyable(const NonCopyable&)=delete;

NonCopyable()=default;

};

struct NoInt {

void f(double i);

void f(int)=delete;

};

This shows the syntax of how to use this new feature. The advantages:

You can explicitly mark functions as deleted: Before you had to move these functions into private section of a class and not provide an implementation. When (accidentally) trying to use such a function you used to get unintuitive compile or linker errors. Now you get a nice message about usage of an explicitly deleted function.

You can prevent unwanted conversions: Using deleted functions is also useful when you want to prevent some function to be called with a different type that can be implicitly converted to your function’s wanted argument type.

Performance with defaulted functions: Compilers tend to write highly optimized code where possible. Implicitly defined constructors or assignment operators e.g. are one of these cases. But as soon as you use inheritance you (mostly) cannot use the implicit versions. Thanks to the new defaulted functions you can do that again. Furthermore it’s possible to change the access policy of an implicitly defined function (which are usually public) using the default syntax.

Variadic Templates

I confess that this is one of the more esoteric features of C++2011 for me. I never really did any serious template meta programming, and variadic templates are just as complicated as the other template programming. Yet I do see the advantages if people start to use it.

Anyhow, I implemented the required parser changes into KDevelop, but proper code completion and DUChain integration might need some time and brain effort :)

static_assert

Now back to simpler things, yet definitely welcome and useful ones. One example are static assertions, i.e. compile-time assertions. The document I linked to contains a list of examples which should show how useful this feature is. Note that we Qt-users know and love the Q_ASSERT macro, but it is a runtime check. Boost users have had a BOOST_STATIC_ASSERT macro for some time, now we will finally be able to use it as well.

STL updates

Ah, before I forget it: Since KDevelop parses the STL includes, you should be able to use all new STL features already. If you spot a serious parser error in one of the include files of GCC 4.6 or 4.7, please notify me.

much much more

These are only some of the new features which I’ve added support for in KDevelop. I’ll try to sit down later today to write part 2, otherwise I’ll do that after I come back from the Fusion festival next week. Anyways, you can stay tuned for features like constexpr, opaque-enum-declarations, class-enums, improved right-shift token handling in nested templates, etc. pp.

After two nights of backporting sleep in my RL branch to fix the deficiency I built up during Randa, I feel somewhat normal again. Time to blog, eh?

Randa

Lets begin with Randa. It was not only my first time there, but also my first time ever to be in the Swiss Alps. And furthermore it was the first time for me to be in the Alps without crying out loud about the lack of snow as I didn’t intend to go snowboarding. You can imagine it was a very pleasant experience for me. I definitely want to come back to go on some more serious hiking trips uphill. But I diverge ;-)

Randa as place for a sprint was simply awesome: Secluded hence no real distractions. Great environment to clean your head, get fresh air and stay focused and productive. Good food, nice people, … I could go on here :) The only negative things I noticed where the unstable networking and the dormitories.

KDevelop Sprint

The KDevelop sprint at Randa was very successful and productive. Here is a group picture of those who attended:

We/I will setup a continous/nightly build- and regression-testing machine for KDevplatform/KDevelop and related plugins. Thanks already for the kind offers for hosting. More on this later

some more plugins from e.g. Quanta will see a released soon. Due to lack of manpower we cannot wait for a stable Quanta release, but some plugins in there are already stable and usable.

we will have some “welcome to kdevelop” page eventually, based on Aleix’s work with the Plasma Dashboard

Niko’s “Browser Like Tabs” mode will be merged eventually, try it out now and give us feedback!

Alexander merged a partial rewrite of the UI framework in KDevelop, bringing lots of new features and less bugs as well as reducing our codebase!

Sven attended his first KDE sprint and continued to work on a kick-ass python language support for KDevelop! Rock on!

I could go on and on here, we really did lots of stuff. It was great meeting you all again, hope to see you soon (at the Desktop Summit?).

GSOC

To finish this already long blog off, here a few notes on my GSOC. As you might have heard, I work on bringing C++2011 (aka C++0x) support to KDevelop. I’ve already pushed some changes to my branch which adapt our parser to support the range-based for loop syntax as well as RValue references and variadic templates. Proper DUChain integration is pending, yet it already makes working with C++2011 features much more bearable! Stay tuned for a more in-depth report.