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

[Jeremy Roman]

My inclination is to follow Google's lead but, since they don't seem likely to adopt 14 internally yet (for reasons that don't really apply to Chromium), attempt to follow the spirit but not necessarily letter of the upstream style guide.

I think the following things should likely be allowed (but am happy to have dedicated threads), because I think it's possible to use them within the spirit (and in most cases, even the letter) of the upstream style guide.

LANGUAGE

- function return type deduction (rarely, only for abstract/templated code)

- generic lambdas (roughly: "auto" in lambda parameters is okay where it would be okay for a local variable; i.e., if it's unclear, then specify the type)

- relaxed constexpr (because now that we're in C++14 mode I don't think it's practical to keep it out)

- variable templates (assuming someone finds them useful somewhere -- it seems no worse than a template function)

LIBRARY

- constant begin/end non-member functions (natural extension of std::begin/end, which is allowed)

- heterogeneous lookup

- std::integer_sequence (in template metaprogramming; we already re-implement it in base/tuple.h)

- std::make_unique (base::MakeUnique was written in anticipation of this)

The stuff that I expect to be more contentious is mostly in C++17.

--
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/CAMGbLiFVvx20mhN_ZMc22NTueLxJV%2B5WSLwYOL7V85ZDo6paaQ%40mail.gmail.com.

[Elliot Glaysher (Chromium)]

I'm in favor of allowing the "obviously ok" things. Mainly std::make_unique and possibly std::index_sequence.

Some of the lambda stuff looks neat and exciting, but I'd defer until there's consensus on those parts since it's not obvious that, say, autos in lambdas would be allowed.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGbLiFVvx20mhN_ZMc22NTueLxJV%2B5WSLwYOL7V85ZDo6paaQ%40mail.gmail.com.

[Justin Schuh]

I just want to voice an enthusiastic yes, because I have a number of improvements to base/numerics currently gated on C++14 constexpr support.

The big things are:

• Make some nice performance improvements, both due to the more reliable expression folding in constexpr and by switching certain behaviors based on compile-time constant detection with __builtin_constant_p (which currently is done in only a few places, because the compiler doesn't propagate compile-time constant detection across function boundaries for non-constexpr functions).
• Get rid of a bunch of really ugly nested ternary operator expressions and other hacks to make C++11 constexpr work in the places I currently use it.
• Convert certain classes of runtime errors into compile-time errors. (I already do this where I can, but C++14 constexpr would allow for quite a bit more.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACuR13ch3M-JfRepcx_9zA05iKY0t3NdRNwYLABGMPyPSmRaoQ%40mail.gmail.com.

[gr...@google.com]

Looking at the features, there's nothing that screams "WE MUST DO THIS", from my POV. But at the same time, I don't think we have to wait for Google C++14 recommendations. (I'm OK if we don't exactly match the Google style guide. We already deviate in parts.)

Many of the features seem useful in smaller ways. Here's what I'd like to see if we did this. 

Language:

* Aggregate initialization

* Generic lambdas

* capture expressions

* constexpr

* Variable templates

Library:
* cbegin and friends

* Heterogeneous lookup

* std::make_unique

* std::integer_sequence 

[Jeffrey Yasskin]

For Googlers' reference (sorry to everyone else), I'll also point out the internal thread about what C++14 features to allow: https://groups.google.com/a/google.com/d/topic/c-style/4Vf92ZMkHuE/discussion.

I can't summarize the whole (long) thread here, but it looks like they're considering banning a couple C++14 features, discouraging a couple more, and allowing the rest.

Jeffrey

On Fri, Aug 4, 2017 at 11:39 AM, Nico Weber <tha...@chromium.org> wrote:

--

[Peter Kasting]

Historically, we didn't even try to follow the Google style guide for years, and we managed to converge to mostly using it.  I'm not too frightened of the pain of "we allowed this but then Google banned it".

So I think it's reasonable to just do our best to make good rulings, and converge (or not!) over time.

Jeff's link of the internal thread (from 2+ years ago!) on this is instructive; the features being debated there would also probably be debated here.  So if we refer back to that thread when ruling we'll probably be good.

For this C++14 process, I also would like us to be biased more towards blacklisting than whitelisting.  There are still a few C++11 features that are TBD in our doc not because there's anything wrong with them but because no one's bothered to ask about them.  I realized rereading this doc today that I approved a CL using one last week.  My suggestion is, let's first batch-allow C++14 stuff if it doesn't seem questionable, and then debate the questionable things (like decltype(auto)) individually.

What would my "batch approve" list look like?

Generic lambdas

Relaxed constexpr

Variable templates

Non-member cbegin/cend

Heterogeneous lookup

std::integer_sequence

std::make_unique

PK

[Antoine Labour]

On Fri, Aug 4, 2017 at 11:39 AM, Nico Weber <tha...@chromium.org> wrote:

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.

Sanity check: does this include MSVC, for which AIUI we want to keep support for a release or 2 in case we have to revert back to it?

Antoine

 

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

--

[Nico Weber]

On Fri, Aug 4, 2017 at 4:32 PM, 'Antoine Labour' via cxx <c...@chromium.org> wrote:

On Fri, Aug 4, 2017 at 11:39 AM, Nico Weber <tha...@chromium.org> wrote:

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.

Sanity check: does this include MSVC, for which AIUI we want to keep support for a release or 2 in case we have to revert back to it?

Excellent question, they have a list here: https://msdn.microsoft.com/en-us/library/hh567368.aspx So most things work, but variable templates and extended constexpr don't, according to that table. (We do still have an MSVC bot on the cq, so if we add a sample use of a feature when we allow it, the cq will check for us if it works.) 

Antoine

 

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

--
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/CAMGbLiFVvx20mhN_ZMc22NTueLxJV%2B5WSLwYOL7V85ZDo6paaQ%40mail.gmail.com.

--
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/CAMeTaZfn47HUOzyPRPbdL876UZNSYFM8M3skefj_i4FZ_VEz_Q%40mail.gmail.com.

[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).