C++11 in KDevelop 4.6

[Andreas Pakulat]

Hi,

this means you're going to require recent MacOSX versions (afaik only
10.8 comes with a working clang) and msvc 2012 has also not been
adopted very widely yet. Not to mention that there's no official Qt
support for that compiler AFAIK.

If you intend to drop support for compiling Kdevelop on Windows once
4.5 has been branched please let me know now so I can stop pursuing
building it on that platform. And I suggest to make this decision
explicit in the cmake files with a platform check.

Personally I think its too early to make C++11 support - which is
incomplete in all state of the art compilers anyway - mandatory. Using
it where it makes sense and providing a fallback like Qt does is a
much better approach for an open source project that lags developers
anyway. Then again, having not used any C++11 features so far, I'm not
even half as excited about it as everyone else seems to be :)

Andreas

PS: If you do ditch support for older gcc's make sure to remove the
ext/hash-map stuff which only exists for gcc 4.3 and older IIRC.

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
>