On Thu, Nov 22, 2012 at 10:49 AM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Thursday 22 November 2012 02:07:57 Aleix Pol wrote:<br>
> On Wed, Nov 21, 2012 at 7:14 PM, Milian Wolff <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br>
> > Hey all,<br>
> ><br>
> > is anyone opposed to open KDevelop 4.6 for C++11? I.e. that means we<br>
> > continue<br>
> > to work as-is and provide a kick-ass KDevelop 4.5. Once we branch 4.5, we<br>
> > enable C++11 mode globally and start using it in master.<br>
> ><br>
> > ######## Reasons:<br>
> ><br>
> > - KDevelop is a free time project and it should be fun to work on it.<br>
> > C++11 is<br>
> > quite a lot of fun, if not only because it's new. This is actually the<br>
> > main<br>
> > reason for me to go down the C++11 route. This would also allow us to<br>
> > learn<br>
> > C+11 which is a benefit for those of us who do professional work-work<br>
> > programming.<br>
> ><br>
> > - Tons of potential performance benefits thanks to constexpr, noexcept, r-<br>
> > value references etc. pp.<br>
> ><br>
> > - Much easier to read code thanks to auto, lambdas, alias templates,<br>
> > defaulted<br>
> > functions, etc. pp. This also leads to better maintainability.<br>
> ><br>
> > - Improved compiler analysis thanks to e.g. static assert, override,<br>
> > final,<br>
> > nullptr, explicit conversion operators, deleted functions, etc. pp.<br>
> ><br>
> > ######## Compilers:<br>
> ><br>
> > See also: <a href="http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport" target="_blank">http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport</a><br>
> ><br>
> > Personally I'd say we should just require these compiler versions and<br>
> > above:<br>
> ><br>
> > clang 3.1 - required for constexpr, lambda, initializer lists, ...<br>
> ><br>
> > GCC 4.7 - 4.6 might even be enough, but 4.7 has some more stuff like<br>
> > delegating constructors, override, final and non-static data member<br>
> > initialization.<br>
> ><br>
> > msvc ctp november 2012<br>
> > (<a href="http://blogs.msdn.com/b/vcblog/archive/2012/11/02/visual-c-c-11-and-the-" target="_blank">http://blogs.msdn.com/b/vcblog/archive/2012/11/02/visual-c-c-11-and-the-</a><br>
> > future-of-c.aspx)<br>
> ><br>
> > ######## Potential Issues:<br>
> ><br>
> > - FreeBSD situation? <a href="http://wiki.freebsd.org/NewC%2B%2BStack" target="_blank">http://wiki.freebsd.org/NewC%2B%2BStack</a> <-- I'm not<br>
> > sure<br>
> > how far they are. But quite frankly, I'd say they can stick to KDevelop<br>
> > 4.5<br>
> > until they have a modern compiler like clang 3.1.<br>
> ><br>
> > - Debian? Wheezy should come with GCC 4.7 if I'm not mistaken:<br>
> > <a href="http://packages.debian.org/wheezy/gcc" target="_blank">http://packages.debian.org/wheezy/gcc</a> Imo it's fine if we only support<br>
> > that<br>
> > version of Debian. All other distros probably already have GCC 4.7<br>
> > available,<br>
> > or will have it in their next distro release in time for KDevelop 4.6<br>
> ><br>
> > - Windows? If anything breaks on MSVC it's imo not an issue as KDevelop is<br>
> > defacto dead on Windows (noone is working on it there). Also considering<br>
> > that<br>
> > the windows team is actually working on proper C++11 support (see link<br>
> > above)<br>
> > its only a matter of time until it has everything we need.<br>
> ><br>
> > - Backporting: Now this is imo a potential issue, but considering that we<br>
> > don't do such a good job in that regard anyways, it's not that big a<br>
> > deal...<br>
> > And most of the fixes we do backport are oneliners which could be done in<br>
> > the<br>
> > 4.5 branches and forward ported to 4.6.<br>
> ><br>
> > ######## Comments? Feedback?<br>
> ><br>
> > Cheers<br>
> > --<br>
> > Milian Wolff<br>
> > <a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
> > <a href="http://milianw.de" target="_blank">http://milianw.de</a><br>
> > --<br>
> > KDevelop-devel mailing list<br>
> > <a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
> > <a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
><br>
> Hi!<br>
> Well honestly, on one hand I get what you mean when you say you want it for<br>
> fun.<br>
><br>
> From my point of view, I'd wait until we switch to KDevelop5/Qt5 where<br>
> C++11 usage is more useful and where all the dependencies will be bumped<br>
> all-together.<br>
<br>
</div></div>This makes sense for a library that is supposed to be widely used. KDevelop<br>
(not even KDevplatform) is such a library.<br>
<br>
Also, the things we could use thanks to the macros in Qt5 would only be<br>
optional. This is explicitly *not* what I want. I do not want to make our code<br>
base more complicated by adding a bunch of #ifdef has_support_for_XYZ.<br>
<br>
Also, such macros would not permit the usage of lambdas and other more<br>
intrusive language changes. After all, we do not want to maintain the same<br>
code base once for C++11 and once for C++03.<br></blockquote><div><br></div><div>I was talking about having it mandatory when the Qt requirement is bumped.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="im"><br>
> On the other hand, if everybody really wants to or if we had a specific<br>
> case where we'd take a really important leap forward I wouldn't strongly<br>
> oppose to bump our requirement. Or putting it in a different way, if<br>
> bumping our compiler dependency makes us to leave some people behind, let's<br>
> not do it just for the fun of it.<br>
<br>
</div>I have yet to find a person who would be left behind by such a change. Note<br>
again: Imo it would be more important to get new developers instead of only<br>
developing for what potential users might have as a requirement. Recent<br>
KDevelop versions don't compile on older distros like Squeeze, RHEL or SLED<br>
anyways, mostly due to our kdelibs 4.6+ requirement.<br></blockquote><div><br></div><div>I know, BSD and Linux shouldn't be much of a problem, so if anything it is Windows and</div><div>MacOS.</div><div><br></div><div>

Maybe you could ask the kde-windows mailing list? I don't know if there's a Mac list...</div><div><br></div><div>In any case, it doesn't hurt to create a new branch and try to figure out where we can start</div>

<div>to take advantage of it and what do we get in terms of performance or code readability.</div><div><br></div><div>Aleix</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="HOEnZb"><div class="h5"><br>
Cheers<br>
<br>
--<br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
<a href="http://milianw.de" target="_blank">http://milianw.de</a></div></div><br>--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
<br></blockquote></div><br><div><br></div>