C++11 in KDevelop 4.6

[Milian Wolff]

On Thursday 22 November 2012 02:07:57 Aleix Pol wrote:
> On Wed, Nov 21, 2012 at 7:14 PM, Milian Wolff <mail at milianw.de> wrote:
> > Hey all,
> > 
> > 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-
> > future-of-c.aspx)
> > 
> > ######## 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.
> > 
> > ######## Comments? Feedback?
> > 
> > Cheers
> > --
> > Milian Wolff
> > mail at milianw.de
> > http://milianw.de
> > --
> > KDevelop-devel mailing list
> > KDevelop-devel at kdevelop.org
> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> 
> Hi!
> Well honestly, on one hand I get what you mean when you say you want it for
> fun.
> 
> From my point of view, I'd wait until we switch to KDevelop5/Qt5 where
> C++11 usage is more useful and where all the dependencies will be bumped
> all-together.

This makes sense for a library that is supposed to be widely used. KDevelop 
(not even KDevplatform) is such a library.

Also, the things we could use thanks to the macros in Qt5 would only be 
optional. This is explicitly *not* what I want. I do not want to make our code 
base more complicated by adding a bunch of #ifdef has_support_for_XYZ.

Also, such macros would not permit the usage of lambdas and other more 
intrusive language changes. After all, we do not want to maintain the same 
code base once for C++11 and once for C++03.

> On the other hand, if everybody really wants to or if we had a specific
> case where we'd take a really important leap forward I wouldn't strongly
> oppose to bump our requirement. Or putting it in a different way, if
> bumping our compiler dependency makes us to leave some people behind, let's
> not do it just for the fun of it.

I have yet to find a person who would be left behind by such a change. Note 
again: Imo it would be more important to get new developers instead of only 
developing for what potential users might have as a requirement. Recent 
KDevelop versions don't compile on older distros like Squeeze, RHEL or SLED 
anyways, mostly due to our kdelibs 4.6+ requirement.

Cheers

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20121122/f388c999/attachment.sig>