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

[Marco Bubke]

+1


It fixes many annoying bugs too!


I would like to use auto for return types if they are returning long types like iterators, tuples, pairs or a mixture of them.


Something like


std::pair<std::vector<SomeClass>::const_iterator, bool> findEntry(const std::pair<std::vector<SomeClass> &items, int value)

{

    auto found = std::lower_bound(items.begin(), items.end(), value, [] (const SomeClass &entry, int value) {

        return entry.someSpecialValue = value;

    });


    return {found, found != items.end()};

}


I like to use function to document the code to avoid long hard to read methods and the code is easily unit testable because the method does one thing. The same would be apply to generic templates.

________________________________
From: Qt-creator <qt-creator-bounces+marco.bubke=qt.io at qt-project.org> on behalf of Eike Ziller <Eike.Ziller at qt.io>
Sent: Monday, January 16, 2017 12:48:13 PM
To: qt-creator at qt-project.org
Subject: [Qt-creator] Proposal: Increase requirements for compiling Qt Creator to GCC>=4.9

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




_______________________________________________
Qt-creator mailing list
Qt-creator at qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20170116/1cdceb44/attachment.html>