Sun, 11/25/2012 - 17:53
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.
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.
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-…)
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.
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.
Sun, 11/07/2010 - 00:16
I’m happy to release Massif Visualizer v0.2. This is mainly a “fix the build-system” release, no new features have been added.
You can download it here: http://kde-apps.org/content/show.php?content=122409
Thanks to the reports by Chris Jones it’s now possible to build and use Massif Visualizer on Max OS X, see e.g.:
He has also submitted the portsfile for inclusion in Macports: https://trac.macports.org/ticket/27168
KGraphViewer now optional
I’ve made the KGraphViewer dependency optional, if anyone does not want it (even though this removes like 50% of the tools features).
I’ve also prepared the steps for moving Massif-Visualizer into KDE Extragear and asked kde-devel for review. I already use the KDE infrastructure now:
git clone git://git.kde.org/massif-visualizer
- Bug tracker:
- Mailing List:
This also means that I’ll shortly get translations by the awesome KDE-i18n-Team, so stay tuned for a 0.3 including translations!
Open Suse Buildservice
I’ve also spent quite some time today battling with OBS and can provide at least packages for Fedora, Mandriva and Open Suse now. I’m still waiting for help on the remaining issues and once they are resolved I’ll add the remaining packages.
- ChangeLog for massif-visualizer v0.2
- * Milian Wolff: set version to 0.2
- * Milian Wolff: fix conditional
- * Milian Wolff: make kgraphviewer dependency optional
- * Milian Wolff: fix FindKGraphViewer.cmake
- * Milian Wolff: fix .po name
- * Milian Wolff: remove some esoteric cli option for XGETTEXT that does not make
- any sense according to Albert
- * Milian Wolff: fix: install libs to make sure they can get loaded on OSX e.g.
- * Milian Wolff: fix compile warning about init order, improve style by having
- just one init per line
- * Milian Wolff: add export macros everywhere, make visualizer helper use the
- Massif namespace as well
- * Milian Wolff: add Messages.sh