Title: The Standards Report

Author: Bob Schmidt

Date: 03 July 2019 00:51:09 +01:00 or Wed, 03 July 2019 00:51:09 +01:00

Summary: Guy Davidson introduces himself as the new Standards Officer and makes his first report.

Body: 

I was elected standards officer at the last ACCU AGM on April 13th. This is my first report on the Standard, so I’m going to start by briefly describing the workings of the committee, how I serve, and how I will be writing my reports for this and future editions of CVu.

C++ was first standardised in 1998: however, that wasn’t the end of the story. Since then Working Group 21 (C++) of Sub Committee 22 (Programming Languages) of Joint Technical Committee 1 (IT) of the International Organisation for Standards (ISO) has been meeting regularly to respond to proposals for improving the language. The first revision of the standard was published 13 years later in 2011, and since then a new revision has been published every three years.

The committee consists entirely of volunteers. Some are sent by their employers while others are private individuals, but all of them are interested in assisting the development of the language. At each committee meeting, a subset of these volunteers meet for six days, Monday to Saturday, to consider proposals. Because of the sheer number of proposals, the committee is divided into four working groups and 21 study groups to provide more focus. At the last meeting in Kona, Hawai’i (yes, it’s a hard life) there were 177 proposals offered for consideration.

The four working groups divide into two parts, one for the language and one for the library. Each part has two components, one where proposals are considered, and one where the actual words of the proposals to be added to the standard are considered: the standard is a legal document, which needs to be unambiguous. The language groups are called Evolution Working Group and Core Working Group. The library groups are called Library Evolution Working Group and Library Working Group.

The study groups, numbering 20 now, are even more focused, covering areas such as concurrency, reflection, HMI and several others. I have been attending committee meetings since Summer 2017, when it was convened in Toronto. My particular interests are the HMI study group, SG13, which focuses on bringing 2D graphics to the standard library as well as audio capture, audio playback, controller input and haptic feedback. I also participate in SG14, which focuses on low-latency environments such as game development, high frequency trading and other similar areas of endeavour.

A proposal typically starts life in one of the study groups, is refined in one of the evolution groups, and is finalised in the appropriate wording group. Such a proposal is described as ‘in flight’ when it is between launch and finalising. Once it has been finalised, it is offered to the committee for voting on inclusion in the standard at the closing plenary session on the morning of the last day of work. Although most proposals gain unanimous support, since they have been refined in several stages and given considerable feedback, this is not always the case. Voting can be surprisingly exciting.

To complete this throat-clearing preamble, observe that the committee meets three times a year, while CVu is published six times a year. I shall attempt to cover language and library updates in alternating issues, although for this issue I shall cover a summary of the Hawai’i committee. Motions to add proposals to the standard come from two groups: the Core Working Group (CWG) and the Library Working Group (LWG). There were 34 motions in total, so I shall cover a few highlights. Let’s start with some significant CWG motions.

The headline additions to the standard were the Coroutines Technical Specification (TS) and the Modules proposal. These features have not been without controversy. The coroutines proposal introduces a general control structure which allows flow control to be cooperatively passed between two different routines without returning. Rather than the pre-empting of thread switches, keywords highlight where control may be passed, enabling asynchronous programming. The naming of these keywords has been discussed at considerable length, and the committee has settled on co_await, co_yield and co_return.

Modules offer a whole new mechanism of abstraction. At the moment C++ implements modularity using #include, a pre-processor mechanism without any knowledge of the language. New keywords have now been added, module and import, while export has been resurrected. In addition to internal and external linkage, identifiers can now have module linkage. Name and argument dependent lookup are changed. This results in an easier way to package C++ objects, with obvious implications for package management tools such as conan and vcpkg.

In addition, the Reflection TS reached publication stage. I will be part of the review committee which will approve the correctness of the TS, which introduces the new keyword reflexpr. Introducing reflection to C++ allows a program to examine its own structure and behaviour at runtime. This is useful for things like serialisation, where you might want to generically serialise classes without having to specify each member datum.

Moving on to the LWG motions, polymorphic allocators were shown a little love with a proposal for an explicit specialisation of pmr::polymorphic_allocator for use as a vocabulary type. This allows for the reduction of the amount of template declaration in classes which require allocators.

My award for most amusing proposal name went to ‘I Stream, You Stream, We All Stream For istream_iterator’ which addressed some of the problems with the design and specification of std::istream_iterator. The proposal does some polishing of the standard which it is to be hoped you won’t notice, and I would have omitted this proposal entirely were it not for the efforts of the author (Casey Carter) in introducing a little levity to proceedings.

The shortest proposal of the session went to ‘Making std::underlying_type SFINAE friendly’, which weighed in at 136 words. Again, you should not notice this change.

Five proposals were passed which changed how requirements are specified in the library. All of them begin with a preamble and this text:

The changes in this series of papers fall into four broad categories.

• Change ‘participate in overload resolution’ wording into ‘Constraints’ elements
• Change ‘Requires’ elements into either ‘Mandates’ or ‘Expects’, depending (mostly) on whether or not they can be checked at compile time.
• Drive-by fixes (hopefully very few)

These papers are a response to the arrival of concepts and contracts, and how this should be incorporated into the standard library.

Finally for this article, there was a proposal to introduce ssize(), a signed version of size(). This contributes towards cleaning up the use of unsigned in the standard library which is usually not the right choice.

In my next report, I will be covering events from the Cologne meeting, which takes place in July.

Guy Davidson Guy Davidson is the Principal Coding Manager at Creative Assembly. He has been writing games for about 75% of his life now. He is climbing through his piano grades and teaching Tai Chi while parenting in Hove and engaging in local political activism.

Notes: 

More fields may be available via dynamicdata ..