Navigation

I’m investigating the feasibility of allowing a subset of C++11 in the KDevelop code base, starting after the branch of 4.5 in a few weeks. I do not want to blindly start going that route just to realize afterwards that I’ve alienated a large portion of our user base. Thus I’d very much welcome if you could read through this blog post and give some feedback which we can build our decision on top.

Here’s the email I sent to the KDevelop development mailing list:

Is anyone opposed to open KDevelop 4.6 for C++11? I.e. that means we continue
to work as-is and provide a kick-ass KDevelop 4.5. Once we branch 4.5, we
enable C++11 mode globally and start using it in master.

Reasons:

KDevelop is a free time project and it should be fun to work on it. C++11 is
quite a lot of fun, if not only because it’s new. This is actually the main
reason for me to go down the C++11 route. This would also allow us to learn
C+11 which is a benefit for those of us who do professional work-work
programming.

Potential Issues:

FreeBSD situation? http://wiki.freebsd.org/NewC%2B%2BStack <— I’m not sure
how far they are. But quite frankly, I’d say they can stick to KDevelop 4.5
until they have a modern compiler like clang 3.1.

Debian? Wheezy should come with GCC 4.7 if I’m not mistaken:
http://packages.debian.org/wheezy/gcc Imo it’s fine if we only support that
version of Debian. All other distros probably already have GCC 4.7 available,
or will have it in their next distro release in time for KDevelop 4.6

Windows? If anything breaks on MSVC it’s imo not an issue as KDevelop is
defacto dead on Windows (noone is working on it there). Also considering that
the windows team is actually working on proper C++11 support (see link above)
its only a matter of time until it has everything we need.

Backporting: Now this is imo a potential issue, but considering that we
don’t do such a good job in that regard anyways, it’s not that big a deal…
And most of the fixes we do backport are oneliners which could be done in the
4.5 branches and forward ported to 4.6.

More Issues

So far a few more concerns where raised:

Mac OSX: only “recent” Mac OSX come with a clang that is new enough. Question is: Which version is that exactly? Do people use KDevelop on an older Mac OS? My personal impression was that most Mac users upgrade asap to the newest OS version, thus this should not be an issue?

Windows: While the team around Herb Sutter is doing a tremendous job in advancing the compiler to provide kick-ass standard support, apparently the Windows users are reluctant to upgrade… But the obvious question is: Should we be held back by an imaginary Windows user base? KDevelop does compile on Windows, and mostly works but afaik there are still some very sore spots, esp. in the CMake project management and the lack of a MSVC debugger integration. Anyhow, would allowing C++11 in the KDevelop code base make it considerably harder for potential contributors? Considering that even now we do not get any contributions from Windows users, I doubt it can get any worse… But I do see that it’s a hen/egg problem.

BSD: FreeBSD is in the process of using Clang. But is that process already finished? If not, is there any ETA? Will there be Clang 3.1? What about other BSDs and Unixoids?

What about unsupported platforms?

Personally, I think KDevelop is currently in a pretty good shape. If some platforms would have to stick to KDevelop 4.5, I don’t see such a big issue in that. We could also think about making it our first “LTS” release and backport essential bug fixes for a longer period.

Why not the Qt way?

Qt 5 makes use of C++11 features where possible in a backwards compatible way. It is of course the correct choice for a library that wants to support multiple platforms. But imo, KDevelop does not have such strict requirements. Rather, it should offer maintainable code that is fun to work on. Thus I am stricly against introducing Q_DECL_CONSTEXPR in our code, instead of using constexpr directly. And of course, in Qt you cannot use auto, nor lambdas, nor many other things as you always have to provide a C++03 fallback.

Lets try it out, no?

As Aleix pointed out, I’ll probably just start a new branch and introduce some C++11 features there. Then we can see whether the gain in code readability or performance is worth the introduction of the mandatory C++11 requirement.

Comments

Greate News ! I’ve been using C++11 in my project for a long time. Opensoure is not about compatibility. When the time KDEVELOP 4.6 show up, gcc 4.8 will be just tooo old for me . I’ll be using gcc 5 already. think about future, dont be hold back by current situations.

It may be risky to rebuild any widely shared libs with -std=c++11 with gcc just yet. KDevelop alone should be probably safe (unless it starts using boost shared libs that were rebuilt with -std=c++98).

Oh, and be sure to blog about any C++11 inspired improvements you do to the code. It’s always interesting to hear about for people like me who haven’t had time time or opportunity to experiment with it yet :)

I can only but agree with other commenters: Go with it, explore the exciting new features it gives you. Especially the fun/maintainability arguments speak to me. And focus on your main platforms, the other ones will inevitably catch up and could ports to them could then be maintained by whoever finds the time/motivation to do so.

I’m on debian, where it is the work of seconds to install GCC 4.7, There is a minor issue if you are working with NVIDIA CUDA, which can currently only work with GCC 4.6, but both can be installed simultaneously, and there are simple workarounds to my problem.

If the fun of using C++11 helps just one kdevelop developer from burning out and staying motivated, i say go for it.

Milian, I think your reasons easily justify the adoption of C++11. I’m glad that you emphasized the importance of your first reason, because it trumps any arguments about compatibility. Writing opensource is, for the most part, about the fun of doing it. Compatibility issues are someone else’s problem. :)

On the technical issues, every platform will catch up to C++11 eventually, it’s just a matter of time. If some platform doesn’t and they want KDevelop so badly, then they will enjoy writing and submitting patches to provide backward compatibility. Most people don’t compile it from source, so they won’t even notice.

Nevertheless, I don’t like it, if one software forces me to update my operating system / distribution.
Why couldn’t I stay say 2 years with my openSuse and do a fresh install not every 8 months?

If I’m not mistaken…
this is about enabling C++11 in KDevelop’s own source code, it should be transparent to you. It will only impact packagers, who actually build KDevelop.
You won’t even need a C++11 enabled compiler to use KDevelop.