> On Jan 16, 2017, at 1:26 PM, Marco Bubke <marco.bu...@qt.io> wrote:
>
> +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.
Actually our coding rules currently only state that auto is allowed "When
assigning iterator types”, but maybe we find a formulation for allowing
“unwieldy template constructs” (which iterators is a part of).
> 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
--
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
