C++11 platform support?

Hello all!

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.

Tons of potential performance benefits thanks to constexpr, noexcept, r- value references etc. pp.

Much easier to read code thanks to auto, lambdas, alias templates, defaulted functions, etc. pp. This also leads to better maintainability.

Improved compiler analysis thanks to e.g. static assert, override, final, nullptr, explicit conversion operators, deleted functions, etc. pp.

Compilers:

See also: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

Personally I’d say we should just require these compiler versions and above:

clang 3.1 - required for constexpr, lambda, initializer lists, …

GCC 4.7 - 4.6 might even be enough, but 4.7 has some more stuff like delegating constructors, override, final and non- static data member initialization.

msvc ctp november 2012 (http://blogs.msdn.com/b/vcblog/archive/2012/11/02/visual-c-c-11-and-the-…)

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

Want to comment? Send me an email!

Comment by microcai (not verified) (2012-11-27 15:50:00)

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.

Comment by Reece Dunn (not verified) (2012-11-27 13:46:00)

I have been using C++11 features in a project of mine (Cainteoir Text-to-Speech) for a while now, incrementally adding them as I evaluate them. I am currently targetting GCC 4.6 and CLang 3.2.

NOTE: CLang 3.1 and earlier have a bug with initializer_lists and constructors — for example, the following fails to compile:

    #include <complex>
    struct A { std::complex<float> c; };
    A a { { 0.1, 0.2 } };

In terms of simplifying code initializer_lists and range-based for help a lot.

Comment by Henry Miller (not verified) (2012-11-27 05:50:00)

Just make sure cmake can detect a bad compiler and give a useful error message. I don’t want to get 1 hour into the compiler (slow computer?) and then get an error message that doesn’t make sense.

Comment by Maciej Mrozowski (not verified) (2012-11-27 02:37:00)

I hope I do not spread any FUD, but..

http://www.mentby.com/Group/gcc-discuss/c98c11-abi-compatibility-for-gcc…

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).

Comment by Elvis Stansvik (not verified) (2012-11-26 13:00:00)

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 :)

Comment by Elvis Stansvik (not verified) (2012-11-26 12:56:00)

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.

Comment by Milian Wolff (2012-11-26 11:24:00)

Joe Vader sent me this by email:

FreeBSD has decent compilers:

Clang 3.1 http://www.freshports.org/lang/clang/

Clang 3.2r163622 http://www.freshports.org/lang/clang-devel/

gcc 4.6 http://www.freshports.org/lang/gcc46/

gcc 4.7 http://www.freshports.org/lang/gcc47/

gcc 4.8 http://www.freshports.org/lang/gcc48/

http://wiki.freebsd.org/NewC%2B%2BStack is about to build a gcc free system, but nobody says you can’t have gcc to compile your software!

Comment by dhardy (not verified) (2012-11-26 08:42:00)

I would say go ahead. The productivity advantages are probably going to outweigh some users having to stick with KDevelop 4.5 for a while.

Just a note: like apparently some of the mac-ports projects, I’ve found Clang 3.1 insufficient. So it could easily be GCC 4.7 or Clang 3.2 you’ll need to depend on.

Comment by Arthur Gruzauskas (not verified) (2012-11-26 08:30:00)

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.

Comment by Jeremy W. Murphy (not verified) (2012-11-26 05:52:00)

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.

When do we start discussing C++1y? :)

Comment by Ivan (not verified) (2012-11-25 18:33:00)

There was a discussion regarding C++11 on k-c-d (started by me and seconded by Martin G.).

The conclusion was:

for libraries and multiplatform core components - no - mainly because of MacOS (gcc 4.2 or something - the same as for Qt/Mac iirc)
for linux/bsd-only things, gcc 4.5 was agreed as an allowed requirement for 4.10, with the possibility to increase it afterwards
for non-core apps,it depends on the target audience.

From my POV, kdevelop is for people who should be able to install more modern compilers on any system, or just download precompiled binaries. So, you could probably require 4.6 or later if you wanted.

FreeBSD has switched to clang 3.1, so it should not be a problem.

Instead of compiler version tests, I’m using feature testing to detect whether the compiler supports what I need from it.

Since we haven’t been able to require 4.6, the features it provides (namely nullptr, override) are done in the same way as in the Qt5. (though, I’m not using the same macro names).

Ch!

Comment by Milian Wolff (2012-11-25 19:34:00)

Note that I want to depend on GCC 4.7, Clang 3.1 or MSVC with the latest preview that includes constexpr and stuff.

And there are MacOS versions which come with a recent clang, no?

Comment by uniq (not verified) (2012-11-25 19:49:00)

Have a look at macports, they are one of the top site to get open source software for a Mac. They list Clang 3.1 (and some pre-release of 3.2) and GCC 4.7. So your requirements can be fulfilled.

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?

Comment by Milian Wolff (2012-11-26 11:03:00)

If you don’t want to update you can stick to KDevelop 4.5, no? Esp. if we’d support it a bit longer that shouldn’t be a problem, or?

Comment by sergio (not verified) (2012-11-25 21:02:00)

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.

Comment by Milian Wolff (2012-11-26 11:04:00)

You are right. KDevelop will stay agnostic to what the user actually does for writing software. This here is only about compiling KDevelop itself.

Published on November 26, 2012.

Tags: