Title: Standards Report

Author: Martin Moene

Date: 05 September 2015 07:17:16 +01:00 or Sat, 05 September 2015 07:17:16 +01:00

Summary: Jonathan Wakely reports the latest on C++17 and beyond.

Body: 

I'd like to start my first CVu standards report by thanking Mark Radford for writing the reports for many years, keeping them interesting and insightful. I hope I can do the same.

Just after Mark’s last report in May’s CVu the C++ committee met in Lenexa, Kansas for another six long days with several groups meeting every day, working on the main standard and a number of Technical Specifications (TS). With a new standard due in 2017 time is running out to decide on the features that will be included, as we will need some time to iron out the bugs and (we hope) get some early implementation experience before it goes to publication. We also need to send the final standard to ISO in plenty of time so they don’t end up publishing it the following year, as nearly happened with the 2014 standard.

Bjarne Stroustrup gave a talk in Lenexa about what he hopes to see in the next standard, his main aims are to:

• Improve support for large-scale dependable software
• Provide support for higher-level concurrency models
• Simplify core language use, especially as it relates to the STL and concurrency, and address major sources of errors.

In his words, these are ‘motherhood and apple pie’, but there are specific proposals being discussed which work towards these goals, which I will cover below. Of course there are also many other proposals that work towards those goals less directly, or towards totally different goals, but I'm not going to focus on those for this report.

Large-scale dependable software

There are two groups working on proposals for C++ modules (N4465, N4466) and several discussions took place during the Lenexa meeting, which I hope will result in some common ground and a unified proposal in time for C++17. Modules will help replace the preprocessor and the simplistic header file model for using libraries, something which appeals to many people.

There are also two competing proposals for contract-based programming (N4378, N4415). These contracts allow preconditions and postconditions of functions to be stated in code, so that they can be verified automatically by the compiler. There seems to be a lot of disagreement about the basic direction that contract checking in C++ should take.

The last active proposal in the large-scale dependable software category is a type-safe union, along the lines of boost::variant. There is only one proposal for a variant type, but the latest revision of it (N4542) is the fourth version, having gone through review sessions at previous meetings, and then changes in response to those previous discussions. There are a number of design decisions that need to be made for a variant type and there is no consensus on the right choices. There have been long discussions at the meetings and even longer ones afterwards by email. Anthony Williams wrote an excellent blog post [1] which covers the main controversial areas, and the comments on the post describe some of the opposing views.

Two of the hottest topics are what should happen if changing the type stored in a variant causes an exception to be thrown and what it should mean to declare a variant using the same type more than once, e.g. variant<string, int, int>. The discussions have gone round and round, apparently without changing anyone’s views or getting any closer to consensus, as different people consider different aspects of the design to be higher priority and don’t want to compromise on whichever part matters to them. Personally I’ve seen enough discussion and don’t feel strongly enough to fight for any particular design. I’d rather have (almost) any kind of variant rather than debating it forever and not getting a variant in the standard at all. The discussions are expected to continue at the next meeting, probably in a larger group than previous discussions. Now that the proposal has graduated from Library Evolution Working Group (LEWG) sessions a wider audience from the full committee will be involved.

Higher-level concurrency models

C++11 gave us some low-level concurrency primitives such as mutexes, atomic operations and thread creation, but nothing higher-level than td::future and std::async. The low-level pieces are considered too difficult for many programmers to use correctly, or just the wrong level of abstraction. It’s important to provide better abstractions that allow programmers to think about the work they want to perform, not about how many threads to create and how to do the error-prone synchronisation needed to communicate between threads.

The Parallelism and Concurrency study group (SG1) have been busy as ever, with the content of the Concurrency TS being completed and ready for a final draft to be considered by the national bodies. Mark previously discussed the Concurrency TS in this column, so I’ll just say that it includes support for running continuations when the result of a future becomes ready, so that operations can be chained together. There are also competing proposals for some form of coroutines (N4402, N4403, N4398). Discussions are ongoing for some form of executor that would allow programmers to pass a unit of work to an executor. The executor would do the tricky job of scheduling work to run in some execution context without the programmer needing to create and manage a thread for every unit of work. Like variant, everyone wants executors, but don’t agree what form they should take.

The Transactional Memory study group (SG5) have been working on the Transactional Memory TS, offering a simpler programming model than explicit atomic operations on individual atomic objects. That TS has now been sent to ISO for publication.

The Networking TS, based on Boost.Asio, also offers a higher-level concurrency model. Although the main purpose of the TS is to add support for working with network sockets and related things like IP addresses and name resolution, much of the Asio library’s strength is the model used for doing I/O, name resolution etc. as asynchronous operations. That means the Networking TS will provide its own high-level concurrency model (there is clear overlap with the more general executor work being done by SG1, but that redundancy will have to be dealt with at a later date). There was an intensive week-long review session of the Networking proposal at the unofficial Cologne meeting in the spring, and LEWG had a couple of sessions in Lenexa to review Chris Kohlhoff’s changes in response to the Cologne review. In most cases LEWG simply agreed with Chris’s suggested changes. As the author of Asio and the proposal he knows the design, implementation and use cases better than anyone, but I think there were some very useful suggestions made in Lenexa which simplify some of the hairier parts of the specification. There will be more work on the Networking TS at the next meeting and I hope to produce an initial draft TS based on Chris’s latest proposal.

Simplify core language use

The biggest news in this area is that reviewing the Concepts TS was finished in Lenexa, so following a final review done by teleconference shortly after the meeting, the TS has been sent to ISO for publication. More recently a complete implementation of the TS was merged into the GCC Subversion trunk. This means there is a working implementation of C++ Concepts available in a major compiler today (if you check out the development sources and build GCC yourself). It’s too early to say whether Concepts will also be part of C++17, but even if it isn’t we’ll have the TS and support in at least one compiler.

Updating the standard library to use concepts is currently being done as part of Eric Niebler’s work on Ranges. His proposal is being reviewed between meetings by teleconference, so there should be more news on that following the next meeting.

The Evolution Working Group are looking at several proposals for simplifying the use of advanced features, including uniform call syntax. This would add core language support for something that the library currently tries to do, but arguably doesn’t do very consistently.

Finally, it would make sense to incorporate some of the utilities in the Library Fundamentals TS into C++17, particularly string_view and optional.

Other news from Lenexa

One of the other hot topics at the Lenexa meeting was a proposal to add several mathematical functions to the C++17 standard library. These functions were part of TR1 back in 2005, but unlike the rest of TR1 were not incorporated into the C++11 standard, due to the reported difficulty of writing good quality implementations. The functions were instead moved into a separate ISO standard, so a standard C++ implementation doesn’t need to include them. That standard has now come up for a periodic review where we have to decide whether to renew it, re-confirm it or retire it. N4437 proposed to add these functions to C++17, as ‘conditionally supported’, so that implementations are still not obliged to provide them, but the committee would not need to maintain a separate ISO standard specifying them. In Lenexa, representatives of the target audiences for these functions argued that they need to be unconditionally supported, so the committee discussed that which proved even more controversial! This will be debated again in Kona.

Finally, a new study group, SG14, covering ‘Games and Low Latency’ was started. They plan to look at subjects related to those topics and try to get members of the game development community to participate in C++ standards work, to ensure their needs are met. It’s not entirely clear whether this is really just about game development, or also relevant to other low latency environments such as electronic trading and some embedded systems, time will tell.

Future meetings

The committee will be meeting in Kona, Hawaii, in October, and then in Jacksonville, Florida in February, and then Oulu, Finland in June. After the Kona meeting we might have a better idea of what will and won’t be included in C++17.

Notes: 

More fields may be available via dynamicdata ..