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

303 views
Skip to first unread message

Nico Weber

unread,
Aug 4, 2017, 2:39:39 PM8/4/17
to cxx
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

unread,
Aug 4, 2017, 2:50:29 PM8/4/17
to Nico Weber, cxx
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)

unread,
Aug 4, 2017, 3:14:57 PM8/4/17
to Nico Weber, cxx
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

unread,
Aug 4, 2017, 3:26:37 PM8/4/17
to Jeremy Roman, Nico Weber, cxx
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.)


gr...@google.com

unread,
Aug 4, 2017, 3:46:38 PM8/4/17
to cxx, jbr...@chromium.org, tha...@chromium.org
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

unread,
Aug 4, 2017, 3:56:39 PM8/4/17
to Nico Weber, cxx
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

unread,
Aug 4, 2017, 4:30:17 PM8/4/17
to cxx
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

unread,
Aug 4, 2017, 4:32:57 PM8/4/17
to Nico Weber, cxx
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

unread,
Aug 4, 2017, 4:35:55 PM8/4/17
to Antoine Labour, cxx
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.

dyar...@yandex-team.ru

unread,
Aug 6, 2017, 8:16:48 PM8/6/17
to Chromium-dev, c...@chromium.org
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

unread,
Aug 15, 2017, 7:31:25 PM8/15/17
to dyar...@yandex-team.ru, Chromium-dev, cxx
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.

Jeremy Roman

unread,
Aug 15, 2017, 8:26:58 PM8/15/17
to dyar...@yandex-team.ru, Chromium-dev, cxx
Bulk library approval CLs (separate so that it's easier to isolate/revert individual changes if they cause build failures):

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

Language features that seemed well-accepted to follow.

Jan Wilken Dörrie

unread,
Aug 16, 2017, 3:34:24 PM8/16/17
to Jeremy Roman, dyar...@yandex-team.ru, Chromium-dev, cxx
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

Jeremy Roman

unread,
Aug 16, 2017, 3:54:53 PM8/16/17
to Jan Wilken Dörrie, dyar...@yandex-team.ru, Chromium-dev, cxx
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

unread,
Aug 22, 2017, 8:30:31 PM8/22/17
to cxx, jdoe...@chromium.org, dyar...@yandex-team.ru, chromi...@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).
Reply all
Reply to author
Forward
0 new messages