C++11 in KDevelop 4.6

Sun Nov 25 15:43:25 UTC 2012

On Thursday 22 November 2012 14:14:15 Aleix Pol wrote:
> On Thu, Nov 22, 2012 at 10:49 AM, Milian Wolff <mail at milianw.de> wrote:
> > 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.
> 
> I was talking about having it mandatory when the Qt requirement is bumped.
> 
> > > 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.
> 
> I know, BSD and Linux shouldn't be much of a problem, so if anything it is
> Windows and
> MacOS.
> 
> Maybe you could ask the kde-windows mailing list? I don't know if there's a
> Mac list...

Yes, I'll do that and write a blog post as well. That should give us some raw 
numbers to base our decision on.

> In any case, it doesn't hurt to create a new branch and try to figure out
> where we can start
> to take advantage of it and what do we get in terms of performance or code
> readability.

Yeah, maybe I just start playing around with this stuff in a new branch. 
Though then people of course won't complain if it doesn't work for them 
anymore and thus we still don't get any idea whether we can merge it or not :)

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/20121125/856eb030/attachment.sig>