Archive for the ‘Uncategorized’ Category

A few minutes ago, the ISO C++ committee completed its fall meeting in Albuquerque, New Mexico, USA, hosted with our thanks by Sandia National Laboratories. We had some 140 people at the meeting, representing 10 national bodies. As usual, we met for six days Monday through Saturday, including several evenings.

The following are some highlights of what we achieved this week. You can find a brief summary of ISO procedures here. The main things to note are:

  • “IS” means “international standard.” In our case, it’s the core C++ standard itself. Think of this as “trunk.”
  • “TS” means “technical specification,” a document separate from the main standard where we can gain experience with new features before putting them into the IS. We have several of these, summarized on the status page. Think of these as “beta branches.”

Modules TS ballot comments: Almost done

A primary goal of the meeting was to address the comments received from national bodies in the Modules TS’s comment ballot that ran this summer. We managed to address them all in one meeting, as well as deal with most of the specification wording issues discovered in the process of responding to the national comments; we discovered one or two areas where the TS wording did not quite match the approved design intent, and so the plan is to finish addressing those and to approve the Modules TS for publication in between meetings via a teleconference, rather than wait for our next face to face meeting in March.

It will be great to get the TS published, and continue getting experience with implementations now in progress, at various stages, in all of Visual C++, Clang, and gcc as we let the ink dry and hammer out some remaining design issues, before starting to consider adopting modules into the C++ draft standard itself. I do not know whether modules will make the feature cutoff for C++20, but a lot of people are working hard to maximize the chances… we’ll know in another 12-18 months when we reach the C++20 feature cutoff.

Second meeting for C++20

This was also the second meeting where we could vote changes into Draft C++20. And we did!

Here are some of the features that were added to C++20 at this meeting. Note: These links currently find the most recent pre-meeting papers and so may not reflect the exact wording adopted at the meeting, but the links will light up to the post-meeting versions of the papers that were actually adopted as soon as those are available in the post-meeting mailing about three weeks from now.

Range-based for statements with initializer (Thomas Köppe). In C++17, we already allowed initialization of if-scoped and switch-scoped variables, just like the ordinary for loop has already had for years. Today, we added the same for the range-based for loop, which gives the same benefit: It enables and encourages locally scoped variables without the programmer having to introduce a scope manually. To take an example from the paper, in C++17 we might write the following to get a variable thing that exists just as long as is needed for the for loop, which avoids a bad pitfall (do you see why the “WRONG” comment is wrong? it might work depending on what f() returns, or it might be undefined behavior):

  T thing = f();
  for (auto& x : thing.items()) {
    // Note: “for (auto& x : f().items())” is WRONG

and now in draft C++20 we can write the recommended local scoping directly with less ceremony of { } and indenting, and follow the C++ Core Guidelines scoping recommendations now also for range-for, as just:

for (T thing = f(); auto& x : thing.items()) {

Bit-casting object representations (JF Bastien). This proposal gives a way to copy the bits of an object in a consistent and simple manner. It adds the new header <bit>, and provides bit_cast for trivially-copyable “bag-o-bits” objects, to easily copy the bits of any such object to another of the same size (the types need not be the same). Note: Yes, we already have memcpy, but bit_cast is safer and also can run at compile time.

Lots of other cleanup. We did various smaller features and cleanup, sometimes to fix bugs, sometimes to improve consistency and generality, and sometimes to make the language a little simpler to use.

  • Example of bug fixes: Draft C++20 sets forth more precisely where constexpr functions are defined (core issue 1581).
  • Examples of consistency and generality: Draft C++20 now supports concepts requires-clauses in more places including lambdas (P0857, Thomas Köppe). Also, stateless (non-capturing) lambdas are now default constructible and assignable, which makes them more convenient to create and use (P0624, Louis Dionne).

Operator <=>, aka “spaceship” (myself). Beyond those, my personal favorite is that the committee adopted my own proposal for the <=> “spaceship” three-way comparison operator (language wording; library wording). Many thanks to all the proposal’s reviewers, including all the authors of previous proposals in this area and especially Jens Maurer and Walter Brown for standardese wording help. This will greatly simplify how to write comparisons.

For example, in C++17 if we want to have a case-insensitive string type CIString that supports comparisons between two CIStrings and between a CIString and a C-style char* string, we would have to write something like the following 18 nonmember friend functions:

class CIString {
  string s;
  // ...

  friend bool operator==(const CIString& a, const CIString& b) { return ci_compare(a.s.c_str(), b.s.c_str()) != 0; }
  friend bool operator< (const CIString& a, const CIString& b) { return ci_compare(a.s.c_str(), b.s.c_str()) <  0; }
  friend bool operator!=(const CIString& a, const CIString& b) { return !(a == b); }
  friend bool operator> (const CIString& a, const CIString& b) { return b < a; }
  friend bool operator>=(const CIString& a, const CIString& b) { return !(a < b); }
  friend bool operator<=(const CIString& a, const CIString& b) { return !(b < a); }

  friend bool operator==(const CIString& a, const char* b) { return ci_compare(a.s.c_str(), b) != 0; }
  friend bool operator< (const CIString& a, const char* b) { return ci_compare(a.s.c_str(), b) <  0; }
  friend bool operator!=(const CIString& a, const char* b) { return !(a == b); }
  friend bool operator> (const CIString& a, const char* b) { return b < a; }
  friend bool operator>=(const CIString& a, const char* b) { return !(a < b); }
  friend bool operator<=(const CIString& a, const char* b) { return !(b < a); }

  friend bool operator==(const char* a, const CIString& b) { return ci_compare(a, b.s.c_str()) != 0; }
  friend bool operator< (const char* a, const CIString& b) { return ci_compare(a, b.s.c_str()) <  0; }
  friend bool operator!=(const char* a, const CIString& b) { return !(a == b); }
  friend bool operator> (const char* a, const CIString& b) { return b < a; }
  friend bool operator>=(const char* a, const CIString& b) { return !(a < b); }
  friend bool operator<=(const char* a, const CIString& b) { return !(b < a); }

With this proposal, the class’s comparisons could instead be implemented as just two ordinary member functions (vs. the 18 that had to be nonmember friends above):

class CIString {
   string s;
   // ...

  std::weak_ordering operator<=>(const CIString& b) const
      { return ci_compare(s.c_str(), b.s.c_str()); }
  std::weak_ordering operator<=>(const char* b) const
      { return ci_compare(s.c_str(), b); }

and objects of this type can still be used just as flexibly and efficiently as if the class author had written all of the above two-way operators in the first version, because now the compiler will rewrite expressions like s1<s2 to (s1<=>s2 < 0) for you automatically. Additionally, unlike the first attempt, this version also documents in code that the kind of ordering being returned is a weak ordering, not a strong (total) ordering. I’m a fan of writing less code to say more, and to say it more accurately. Please see the paper linked above for more details.

In related news, at this meeting the Library Evolution subgroup also began considering David Stone’s proposal to apply operator<=> to the standard library, and it got a warm reception and is expected to progress over the coming meetings. If it succeeds, we hope it may possibly let us get a small reduction in the size of the standard library specification as well as a result. Additionally, at this meeting we discovered that having <=> opens an unanticipated door for language evolution: Because the default operator<=> is guaranteed to be memberwise, so that we can know those are its semantics at compile time, a brand-new proposal by Jeff Snyder can leverage it to solve the remaining problems that before prevented us from using non-built-in types as non-type template parameters; we’ll see more of his proposal at our next meeting. That’s a good sign of a feature that is generally useful in the language beyond just its intended use cases.

We also approved extensions to the standard library:

atomic<shared_ptr<T>> (myself, Alisdair Meredith): This was originally my proposal and I got it into the Concurrency TS; many thanks to Alisdair Meredith who got it the rest of the way into draft C++20 over the past two meetings. There are changes since it appeared in the Concurrency TS, including to make it use the name I originally proposed (and not “atomic_shared_ptr<T>”).

Here’s more that we got at this meeting on the standard library side. If you notice “constexpr” being mentioned a few times above already, and some more below, that’s no accident; in Library subgroup chair Marshall Clow’s words, “the future of constexpr is bright.” The following other progress also includes more work on enabling features to work at compile time, including most of the rest of the standard algorithms:

(Aside: At this meeting, the Evolution subgroup also provisionally allowed constexpr (compile-time) new, vector, and string. Stop a moment, and think about what that means. — That is not yet in C++20, but it’s on its way and could be approved for draft C++20 in another few meetings… and if this all reminds you of the CppCon “constexpr all the things!” talk title, you’re exactly right.)

And much more. Thanks to all those proposal authors and the issues list proposed wording contributors and all their helpers, without which this team effort would not succeed meeting after meeting. None of the proposers could get it done without all the contributions of many people who work tirelessly all the way from design feedback to detailed wording review, usually for no public glory, and we appreciate their indispensable help. For any of the above papers you happen to have interest to click on, please be sure to look also at the Acknowledgments section, many of which are quite extensive and deservedly so.

We also continued incubating other work. In particular, the Reflection study group had presentations, and gave direction and feedback, on static reflection for functions, as well as design feedback on Section 5 of my metaclasses paper. The Undefined/Unspecified Behavior study group met for two days with our sister committee WG23 (Vulnerabilities) co-located at the same venue to start work on a C++-specific document about programming language vulnerabilities and guidance, in conjunction with (and already providing new feedback for) the C++ Core Guidelines.

What’s next

Here’s an updated snapshot of our status:


Thank you again to the 140 experts in Albuquerque this week, and the many more who participate in standardization through their national bodies! Have a good winter… we look forward now to our next meetings in March (Jacksonville, Florida, USA) and June (Rapperswil, Switzerland).

Read Full Post »

I was also interviewed recently by Anastasia Kazakova for the CLion blog, and that interview is now live:

Toward a more powerful and simpler C++ with Herb Sutter

Topics include:

  • Concepts and modules (and coroutines) as the true hot topics right now
  • How my work on metaclasses was motivated and developed
  • Obligatory aside on operator<=> which grew out of the same work
  • Good and bad ways to learn from other languages and their experience
  • What are the next questions to be answered for metaclasses proposal
  • What has been the committee’s feedback so far
  • How can we expect to see reflection, compile-time code, injection, and metaclasses both progress in committee and get built into production compilers
  • How toolable are today’s C++11/14/17 features, and what about toolability for metaclasses

Read Full Post »

The Qt World Summit videos were just posted, including my talk which was a condensed (40-minute) version of my CppCon 2017 metaclasses talk with some small tweaks for a Qt-specific audience.

Here it is below:

Read Full Post »

Last week I did an interview by email with InfoQ. It just went live:

C++17 is Here: Interview with Herb Sutter

Topics include:

  • What parts of C++17 should developers get most excited about?
  • Why didn’t concepts make it into C++17?
  • What will be the major focus areas for C++20?
  • What do you find interesting or inspiring about new languages like Rust, Swift, and Go?
  • Any new books coming? What’s your main focus today?

Read Full Post »

In my household, iOS 7 was sickening — literally. When it came out with its flashy parallax home screen and (IMO too often gratuitous) motion effects, my wife was one of the many people it immediately made motion-sick. After 30 years of loyally loving Apple products, my wife almost had to dump her iPhone. It was so bad that it’s the only time in my life we’ve written an email directly to the CEO of a company; we didn’t expect Tim Cook to reply, but we hope it helped raise awareness, and fortunately (likely not because of us, even slightly, but very happily), Settings > Accessibility > Reduce Motion came long just in time, and iOS was usable again.

Now iOS 11 has done it again. Just unlocking the phone is motion sickness-inducing because the lock screen now flies upward out of the way on every unlock, even if you have Settings > Accessibility > Reduce Motion enabled. (What happened to “No means no”?) And there appears to be more motion again around the lock and home screens and when just opening and switching the built-in apps, so now my wife is feeling ill again in the first 10 seconds of every phone session since she upgraded, and we’re having Android conversations again. And we don’t want Android. Really.

iOS is supposed to be the most usable phone OS, but you can’t use something if you can’t look at it.


Open letter to Apple designers:

We love your work because you love usability, and especially in recent years you love accessibility. Please, get back to those roots.

What is it with all the motion lately? You are known for minimalism, and that “design is how it works.” Design is not about “how it looks” eye candy — gratuitous motion is not a feature, yet it seems that in recent releases you have had a temptation to go for “cool” effects that do not improve usability. Please resist. I hope we can all agree that parallax on the home screen has insignificant effect on improving usability; I turned it off as soon as I could even though I’m not motion sickness-prone (seriously, this aspect of iOS reminds me unflatteringly of Clippy bouncing around). And yes, I realize that you likely made the iOS 11 lock screen swerve careen glide up on unlock in order to teach that “hey look! see? it lives up there just off the top of the screen” so that we remember that we can now pull it down anytime to get it back — yes, we know, we learned it once the first time, could we please now not have to live with that animation forever? Please stop with the careening screen elements. You know what Nancy Reagan would say about the animations: Just Say No.

Minimal-change proposed resolution: Please, just make all the new motion effects, including the fly-away lock screen, respect Settings > Accessibility > Reduce Motion. (Translation: “No means no.” We said No already. Please respect it.) Or give us a new way to turn it off. Please.

We want to keep using iOS, but we can’t use it if we can’t look at it. We don’t want to have to switch to Android to get a phone we can use. Don’t let Android win on usability, which is supposed to be your home turf — and don’t let Android win on accessibility, which is so important these days and which I know is important to you.

Thank you for your consideration and help.


If you know of a workaround that can disable these awful motion effects, please mention it in the comments. (But please don’t suggest jailbreaking, which isn’t an option for us because that would be license-violating and security-compromising.)

Read Full Post »

My CppCon talk yesterday is now on YouTube. You can read more about in my July blog post on “Metaclasses: Thoughts on generative C++” which contains links to the current paper and some examples that work so far on the live prototype compiler cppx.godbolt.org.

Thanks again to Bjarne Stroustrup for making C++ so general and powerful with just a single kind of “class” (essential for this work), to Andrew Sutton for implementing the prototype metaclasses compiler, to Matt Godbolt for hosting it on his site, to everyone on the committee and in the community on whose work this is trying to build and have provided comments and feedback, and to Bash Films and CppCon for making these videos available so quickly. As in previous years, the CppCon videos will also be available on Channel 9 as well, though that usually takes a few extra weeks to happen.

Read Full Post »

[revised 9/8 to reflect that there is no need to wait till the next WG21 meeting]

As I mentioned in my Kona (March) trip report, WG21 (the ISO C++ committee) completed work on C++17 at our March meeting. At that point it was technically finalized, and since then we have been in the final procedural endgame of formal ISO approval and publication.

Today, I’m pleased to report that the last major ballot was completed: A few hours ago, the C++17 DIS (Draft International Standard) ballot came back with 100% approval, 23 editorial comments, and no technical comments. Unanimous approval of a DIS means that we get to skip the FDIS ballot (as we hoped) and proceed directly to publication. As far as ISO is concerned, we are now done and they are just waiting for us to update the document editorially and send them the final PDF we want to be published.

So the remaining steps are:

  • The project editor (Richard Smith) and helpers will review and resolve the editorial comments, and any other pending editorial tweaks they feel like fixing (e.g., speling, formatting). This includes generating the official record of response paper summarizing what was done for each editorial DIS comment received.
  • We send the final PDF to ISO for publication, and ISO after a month or two ISO publishes it in the ISO store.

Note again that all this is just formally putting a bow on C++17. WG21’s active project now is C++20, and we already began work on that at our last meeting in Toronto, including to add a major feature (concepts!), and we’ll continue serious work on that in Albuquerque and beyond.

This is a product of many people’s labors and many often-unsung efforts. Thank you again to the hundreds of participants in the ISO C++ committee, and many interested commenters and helpers in the community, for all your work and support for C++ standardization.

Read Full Post »

Older Posts »