C++11 in KDevelop 4.6

[Andreas Pakulat]

Hi,

On Wed, Nov 21, 2012 at 8:05 PM, Milian Wolff <mail at milianw.de> wrote:
> On Wednesday 21 November 2012 19:33:30 Andreas Pakulat wrote:
>> this means you're going to require recent MacOSX versions (afaik only
>> 10.8 comes with a working clang)
>
> Is that an issue? I have no idea when it comes to MacOSX, but the people I
> know tend to upgrade ASAP to the newest MacOSX versions. Furthermore, I know
> of not a single user of KDevelop on Mac. There was one of the AMSN developers,
> question is whether he still uses it. Also see below.

Since KDevelop does not collect usage statistics you don't have the
slightest clue who's using it on which MacOSX platforms. You usually
only get to know when things don't work which is hopefully the
minority.

>> 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.
>
> So you want to work (or already do work) on KDevelop support for Windows?

I did want to yes, but its not looking good right now. Thats unrelated
to kdevelop though, I don't even get the stack built so I can run any
KDE app :( If this does not get resolved soonish I'll probably drop
the idea again for a few months.

> What prevents you from using the MSVC CTP? Why is C++11 support an issue here?
> The compiler is even available free of charge as far as I know? What exactly
> is the issue?

I've been following msvc releases for the last 5 years and for someone
working on things in his spare time it simply pays off to stick with
the reliable slightly older but widely adopted compiler version than
jumping to the newest beta of the next cool version. Thats why I'm
using msvc2010

> Note: I don't want to drop Windows support alltogether. I just don't want to
> be kept back by a platform with imaginary user base.

Thats the same thing, if you want to make use of features that are not
available on a platform and don't want to provide a fallback then
you're essentially dropping that platform as a target.

Just in case its not clear, I don't give a shit wether windows is
supported or not, most of the time vim is enough to work on windows. I
still have hopes though that one day I don't have to switch to linux
to do more serious refactorings or writing bigger amounts of new code.

>> Personally I think its too early to make C++11 support - which is
>> incomplete in all state of the art compilers anyway - mandatory.
>
> Did you take a look at the features supported by the compiler versions I
> listed below? The fact that some parts like the threading and memory model
> stuff is not yet supported, doesn't mean we cannot start using C++11 for the
> rest?

Yes and the short names on the left most of the time did not mean
anything to me. I'm not a language expert in C++ so I don't have a
clue about all these new features, unless I'm reading a description of
what that name means and how it helps in getting better code.

>> 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 :)
>
> Why do you think will we get less developers when we complicate things?

Because you lower the barrier of entry, you do not have to require the
new users to provide the fallbacks.

> Imo
> writing constexpr is much easier and straight forward compared to going
> through the Q_CONSTEXPR indirection. Also, don't you think we become more
> interesting for new developers by offering them to use C++11 in our code base?

I did not use either so far so I have no clue which one is easier. And
more interesting for new developers requires those developers to be
able to build kdevelop with their environment. And by limiting the
number of compilers than can build kdevelop you're making the chances
of overlap between the two smaller.

Anyway, I just wanted to raise some points that I think should not be
forgotten just because the main developer run a bleeding edge linux
system that can handle all the new stuff already. Maybe it really is
time to try this out and see how it works out, you'll probably notice
rather sooner than later when people complain about non-compiling code
because their gcc is a bit older. So you have a chance of adjusting
your intended way in case requiring C++11 features turns out to be a
problem before all the codebase makes use of those features.

Andreas