[Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9

[Eike Ziller]

I propose increasing the GCC compiler requirements for compiling Qt Creator, starting with 4.3, to GCC >= 4.9.
https://codereview.qt-project.org/182471

This allows us to use parts of C++14, which will most probably not have a huge impact on how we write code, but contains a few goodies in some special areas anyhow.
(http://en.cppreference.com/w/cpp/compiler_support)

As far as I can see, the main supported platform (in the default configuration) that we will loose when doing this is Ubuntu 14.04 which should be acceptable with 16.04 being the “current” LTS.

*_t versions of various type traits
—----------------------------
std::decay_t<T> (instead of “typename std::decay<T>::type”)
std::result_of_t<T>
std::enable_if_t<V>
…
No reason not to use it.
https://codereview.qt-project.org/182060

make_unique and make_shared
—----------------------------
Makes the code shorter and more readable, and has a few smaller benefits.
Afaics no reason not to use it.

reverse iterators std::(c)rbegin/(c)rend
—----------------------------
Afaics no reason not to use it.

(make_)(integer|index)_sequence
—----------------------------
You probably don’t care, but I do (a little) ;)
https://codereview.qt-project.org/182231

decltype(auto)
—----------------------------
Since we do not allow “auto a = b;” in our coding style, this is probably mostly useful in some situations with templates to avoid writing
auto foo(….) -> decltype(….)
when the return type depends on function arguments. Can be written as
decltype(auto) foo(….)
in the cases where the decltype expression was the expression that is returned.

https://codereview.qt-project.org/182096

auto for normal functions
—----------------------------
So far our coding style only allows auto for a very limited set of situations:
	• when the type is repeated in the same statement
	• when the type is some unwieldy template construct (e.g. iterator types), or lambda
	• implicitly for the return value of lambdas

I think we should keep use of auto restricted, and keep the rules as is. The
gain in readability is worth the effort.

Generalized Lambda Captures
—----------------------------
[foo = bar + 1]() {…}
Probably not many uses for it, but I also don’t see a reason why not to use it occasionally.

Generic lambda expressions
—----------------------------
Allows using “auto” in parameter lists for lambdas:
"[](const auto &name) {…..}” instead of “[](const QString &name) {….}”,
“[](auto kit) {…}” instead of “[](Kit *kit) {…}”.

I’m not sure about this one.

It can be useful when actually using it polymorphic, i.e. reuse the lambda for different types, but that is not happening often in our code.
In the “normal” case it can be more concise if the type(s) that are passed to the lambda have long names or are templated. For the template case we can of course apply the usual rule for “auto”.
If the lambda is used as a parameter to some algorithm (anyOf, transform, findOr), the type of the parameter should be pretty clear from context.
In other situations, it is not so clear.
Also the gain, for single-use lambdas and when the type names are not too long, is very small.

Br, Eike
-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B