C++11 in KDevelop 4.6

[Aleix Pol]

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

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.

Aleix


>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20121122/2e28f3e5/attachment.html>