+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...@qt-project.org> on
behalf of Eike Ziller <eike.zil...@qt.io>
Sent: Monday, January 16, 2017 12:48:13 PM
To: qt-creator@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.zil...@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
_______________________________________________
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
