C++14 is here. Should we use it?

[Nico Weber]

Hi,

(bcc chromium-dev, blink-dev -- join us over at cxx@ if you want to participate in the discussion)

as of last week, I think all our toolchains support C++14.

What's new in C++14? See http://chromium-cpp.appspot.com/#core-review-14 and http://chromium-cpp.appspot.com/#library-review-14 -- thanks to jbroman for helping with documenting this. It's a fairly small language extension, but some things look useful (std::make_unique could replace base::MakeUnique, the extended constexpr support can be handy in some limited circumstances like e.g. base/numerics, etc).

However, the google style guide doesn't make any recommendations about C++14 yet. So we'd have to guess which recommendations google style will make about C++14, and if we guess wrong that'd be somewhat unfortunate.

Do people have an opinion on what to do? Hold off on C++14 stuff completely? Only allow "obviously ok" things (e.g. make_unique, but maybe not generic lambdas and generalized constexpr)? Do our best at guessing and then clean up after the fact when we guess wrong?

Nico

[dyar...@yandex-team.ru]

Hooray for C++14!

Generic lambdas are amazing - let's allow generic lambdas! Using algorithms without horrible typing!

[](const std::unique_ptr<long_namespace::GodKnowsHowLongThisNameIs>& lhs,

   const std::unique_ptr<long_namespace::GodKnowsHowLongThisNameIs>& rhs) {

  return lhs->name < rhs->name

}

Can you please tell, why do we have troubles with modern C++ support?


пятница, 4 августа 2017 г., 21:41:01 UTC+3 пользователь Nico Weber написал:

[Jeremy Roman]

It seems like there's generic support for a number of basic features. I'm going to run through them moderately quickly, starting with the least controversial ones (like std::make_unique).

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/2f1151aa-2c31-496c-94e9-819636c867da%40chromium.org.

[Jeremy Roman]

Bulk library approval CLs (separate so that it's easier to isolate/revert individual changes if they cause build failures):

std::make_unique: https://chromium-review.googlesource.com/c/616016/

std::integer_sequence: https://chromium-review.googlesource.com/c/616082/

heterogeneous map lookup: https://chromium-review.googlesource.com/c/616262/

std::cbegin: https://chromium-review.googlesource.com/c/616268/

Language features that seemed well-accepted to follow.

[Jan Wilken Dörrie]

This is almost too trivial to ask, but I would also like to see the two ranges overloads for std::mismatch, std::equal and std::is_permutation: http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3671.html

I'm mostly interested in std::equal, as this allows easy implementation of operator== for custom container types, but the overloads for mismatch and permutation should be added for consistency as well.

Furthermore, the two ranges std::equal is already used in the code base: https://codesearch.chromium.org/chromium/src/base/containers/span.h?l=71

Best,

Jan

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACuR13cbBpy%3DR5fo2-a427kXp4dcUtpBzqAP2wuS2z%2B2UbBDNg%40mail.gmail.com.

[Jeremy Roman]

On Wed, Aug 16, 2017 at 3:34 PM, Jan Wilken Dörrie <jdoe...@chromium.org> wrote:

This is almost too trivial to ask, but I would also like to see the two ranges overloads for std::mismatch, std::equal and std::is_permutation: http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3671.html

I'm mostly interested in std::equal, as this allows easy implementation of operator== for custom container types, but the overloads for mismatch and permutation should be added for consistency as well.

Furthermore, the two ranges std::equal is already used in the code base: https://codesearch.chromium.org/chromium/src/base/containers/span.h?l=71

I'm inclined to agree. I'm happy to review a CL listing the overloads in styleguide/ if you think it would help, but in my mind these overloads are sufficiently trivial additions to the language as not separate approval.

[bruce...@chromium.org]

One thing I would caution about is that the compiler situation for Chrome on Windows is still in flux. We switched to clang but hit a few issues so we temporarily returned to VC++. We expect to switch back to clang soon but we would like to retain the option to return to VC++ if needed. Currently that means VC++ 2015, with its C++14 conformance limitations.

We may be able to switch to VC++ 2017 Update 3 soon which will raise our conformance floor - by the end of the year VC++ 2017 plans to have full C++14 compliance and significant C++17 compliance as well (IIRC).