Taking polls during the Friday afternoon plenary session — the room is hotter than it looks

Yesterday we just wrapped up our fall ISO C++ committee meeting in Kona, HI, USA. We normally meet in windowless rooms all week, but because of the committee’s current size we had to use the hotel’s largest space which was open-air (though technically still windowless).

It was a busy week. During the days from 8:00am-5:00pm, usually six sessions ran concurrently: Core (CWG), Evolution (EWG), Library (LWG), Library Evolution (LEWG), Concurrency (SG1), and usually at least one more subgroup such as Numerics. In the evenings, from 7:30-10:00pm, there were more evening sessions than evenings, and sometimes three would run concurrently. Daily sessions started at 8:00am, and most of us attended the evening sessions until 10:00pm each day, after which many people still went back to their rooms to update papers until midnight. (This schedule is pretty usual for ISO C++ meetings.)

What we did

We approved a number of actions — see STL’s great Reddit post for a summary, and some details on the library parts. Here are a few more notes from my own perspective.

First, actual major deliverables:

Concepts TS: It’s published! We did that between meetings, but it’s worth mentioning again here. There was initial discussion about putting it directly into C++17; we expect to seriously consider that at our next meeting.

Concurrency TS: We approved the final Concurrency TS for publication. It’s done!

Parallelism TS: The Concurrency group decided to pursue airlifting version 1 of this TS (which has already been published) into the draft for C++17, and we expect to see that proposed to the full committee at our next meeting. This week, we went ahead and also approved starting official work on version 2 of the Parallelism TS.

Ranges TS: We approved starting official work on a Ranges TS based on Eric Niebler’s great working text. The goal is to send it out for its main ballot in March following our next meeting.

Networking TS: We approved starting official work on a Networking TS based on Chris Kohlhoff’s excellent wording, evolved from his Boost.ASIO library.

Next, other major work:

Modules has reached a milestone: design agreement! This was done by separating “phase 1” and “phase 2” of modules, and greenlighting phase 1 to proceed to wordsmithing for adoption (hopefully at our next meeting) into a new Modules TS, while in parallel continuing work on an expanded phase 2 which can follow.

Variant has reached a milestone: design agreement! This consumed our main Monday evening session. For the first time, the broader set of committee members agreed on its design and we expect to see (and hopefully approve) actual wording at our next meeting. Its initial target will likely be Library Fundamentals v2. (Spoiler for those following along at home: It’s the same variant that LEWG approved at our last meeting in Lenexa, but after an exception renders the variant invalid, attempting to access the invalid variant causes defined behavior, such as throwing an exception, instead of undefined behavior. This was acceptable to three major constituencies: people who wanted a zero-overhead variant, people who wanted a variant without an omnipresent empty state, and people who wanted a variant without undefined behavior.)

Contracts seem to have made a breakthrough in getting the various parties to agree on the nitty-gritty details of a design. This consumed two three-hour evening sessions on Tuesday and Wednesday nights. If this holds, we expect to see a combined proposal that for the first time achieves broad agreement in time for our next meeting.

Reflection continues to make slow but steady progress. Chandler Carruth reminded us that several initial proposals have already started progressing through the committee.

There’s more, but those are some of the highlights.

Next meetings

Our next meetings (always listed here) will be Jacksonville, FL, USA on Feb 29 – Mar 5, 2016 and Oulu, Finland on Jun 20-25, 2016. Note that the Oulu meeting is when we plan to feature-complete C++17 and send it out for its main comment ballot, so that will be a big meeting. (It will also be within a few dozen kilometers of the Arctic Circle and is deliberately scheduled so that the summer solstice occurs during the meeting, so the joke is that there will likely again be lots of post-dinner sessions in Oulu, but for once we can guarantee there will be no evening sessions!)

My talk at CppCon is now available online: “Writing Good C++14… By Default” (slides)  It’s about type and memory safety for C++ — not a small target.

Definitely watch Bjarne’s keynote first. This talk is largely designed to be “part 2” of his keynote.

I’m very excited about the C++ Core Guidelines to promote modern C++14 style and this effort to achieve type and memory safety dovetails with that. Bjarne and I merged our efforts last winter, and with the help of many people brought it to this point where it’s ready to open up, and we hope this work can continue making progress.

The CppCon 2015 program is up! If anything this is an even stronger program than last year, which is saying something.

My name isn’t on it yet, but yes, I am giving a talk at CppCon. It should be announced this week.

I just posted my Lenexa ISO C++ trip report over on isocpp.org covering our recent meeting.

The ISO C++ committee is shipping more work sooner via concurrent Technical Specifications, but it’s still fairly new to find ourselves doing so much work that the “new normal” is to issue an international ballot from every ISO C++ meeting. This time, we completed three Technical Specifications (Transactional Memory, Library Fundamentals, and Parallelism) and sent out another for its comment ballot (Concurrency). We also did quite a bit of forward-looking planning for C++17, which is much closer than one would think since we’re aiming for a comment draft in mid/late 2016.

And check out the CppCon angle… it’s great to see the committee/community interaction and collaboration, and I can’t wait for CppCon in September and the fall ISO C++ meeting in October.

Today it was my pleasure to announce a financial assistance policy for ISO C++ meetings. You can read about it at the announcement here.

Today, Vikram Ojha asked via email:

I was just thinking why we removed “int” as default return type from C++ which was there in our traditional C type. Why we made such changes, is it to make language more safer?

Short answer: Because it’s ‘inherently dangerous’ in the words of the C committee.

For C++, see D&E (The Design and Evolution of C++) index “implicit int” which takes you to section 2.8.1. For C, see the C99 Rationale section 6.7.2 — interestingly, you can’t search for “implicit int” because that term isn’t used — this is where the string to search for is “inherent danger” :).

Cribbing from Bjarne’s writeup, “implicit int” was removed some 20 years ago for several reasons, including code clarity and in additional avoiding special cases, to simplify C++ code and/or the C++ grammar.

For example, what does this mean?

void f(const T);

In modern C++, it can mean only that f has a const parameter of type T that is unnamed.

If we had implicit int, this would be less obvious: Could it also be a const parameter of type int named T?

There are a number of other cases where just omitting the type, with the meaning that it’s a certain fixed type, makes the grammar and/or the program harder to think about than it should be. So the ability to do that was removed in both C and C++.

[Edit: I really like the ‘range of values’ several commenters proposed. We do need something like that in the standard library, and it may well come in with ranges, but as you can see there are several simple ways to roll your own in the meantime, and some third-party libraries have similar features already.]

Today a reader asked the following question:

So I’ve been reading all I can about c++11/c++14 and beyond when time permits.  I like auto, I really do, I believe in it.  I have a small problem I’m trying to decide what to do about.  So in old legacy code we have things like this:

for (int i = 0; i < someObject.size(); i++) { … }

For some object types size might be unsigned, size_t, int, int64_t etc…

Is there a proper way to handle this generically with auto?  The best I could come up with is:

auto mySize = someObject.size();

for (auto i = decltype(mySize){0}; i < mySize; i++) { … }

But I feel dirty for doing it because although it actually is very concise, it’s not newbie friendly to my surrounding coworkers who aren’t as motivated to be on the bleeding edge.

Good question.

First, of course, I’m sure you know the best choice is to use range-for where that’s natural, or failing that consider iterators and begin()/end() where auto naturally gets the iterator types right. Having said that, sometimes you do need an index variable (including for performance) so I’ll assume you’re in that case.

So here’s my off-the-cuff answer:

  • If this isn’t in a template, then I think for( auto i = 0; etc. is fine, and if you get a warning about signed/unsigned mismatch just write for(auto i = 0u; etc. This is all I’ve usually needed to do.
  • If this is truly generic code in a template, then I suppose for( auto i = 0*mySize; etc. isn’t too bad – it gets the type and it’s not terribly ugly. Disclaimer: I’ve never written this, personally, as I haven’t had a need (yet). And I definitely don’t know that I like it… just throwing it out as an idea.

But that’s an off-the-cuff answer. Dear readers, if you know other/better answers please tell us in the comments.


Get every new post delivered to your Inbox.

Join 2,716 other followers