Title: ACCU Standards Report

Author: Bob Schmidt

Date: 04 September 2018 18:30:47 +01:00 or Tue, 04 September 2018 18:30:47 +01:00

Summary: Emyr Williams reports the latest from the C++ Standards meetings.

Body: 

Sadly, I missed the deadline with my last report, which is entirely my fault. However, I hope to make up for it with the latest offering. The usual caveats apply. I would like to offer my everlasting thanks to Roger Orr for being kind enough to proof-read what I’ve written. Any errors that remain are mine alone.

First up, there’s been some news about new personnel in the ISO committee, with ACCU’s Nina Ranns elected to be the WG21 secretary, which is awesome, along with ACCU’s Code Critique master Roger Orr, who has been invited to join the direction group, which is a small by-invitation group of experienced participants who are asked to recommend priorities for WG21. So heartiest congratulations to them both.

So, over a week in June, the C++ ISO Committee met in Rapperswil, which is in Switzerland, hosted by HSR Rapperswil, Zühlke, Netcetera, Bbv, SNV, Crealogix, Meeting C++ and BMW Car IT GmbH. It was well-attended, with 140 people at the meeting and 11 national bodies represented.

This was the penultimate meeting for merging major language features in to C++ 20, so priority was given to the larger proposals that could make C++ 20 or make solid progress towards making it in to C++ 20.

The second version of the Parallelism TS (N4725) is now finalised and, by the time this article is published, will be sent for publication by the various national bodies, including BSI, and people will be able to make use of it portably among compiler vendors that support it in their compilers.

The draft Reflection TS has been sent out to the national bodies for ballot. This is normally the final step before publication, and by the time the standards body meets again, the results of the ballot should be in and, if there are no glaring issues, they will move on towards publication.

Some of the highlights include:

Contracts adopted for C++ 20 (P0380R1)

This feature of the language provides a structured way to express function preconditions and postconditions in code.

For example, consider the following code snippet (with thanks to Jose Daniel Garcia Sanchez, the paper’s author, for proof-reading my sample):

  double deposit(int account_number, 
    double deposit)
  [[expects: acount_number != 0 ]]
  [[ensures result: result > 0 ]] 
  {
    double current_balance =
      get_balance(account_number);
    // this is within a function body,
    // so it can access everything within the
    // function itself.
    [[ assert: new_balance == 
      current_balance + deposit ]];
    return new_balance;
  }

The contract is made up of three parts. There is the pre-condition (expects), the post-condition (ensures), and the assertion (assert). As can be seen from the above code sample, the post- and pre-conditions are defined outside of the function body, so they can’t access the local variables within the function, other than any arguments that are passed to that function.

Contracts are also considered part of a function’s interface, and they operate on the external view of the function.

In his blog, Herb Sutter gives three points as to why contracts are a big deal. I won’t go in to detail in this article, but in essence they are:

1. Having decent contracts support is the first big step of reforming error handling in C++, and it will apply all the lessons learned over the last 30 years or so.
2. It will allow for the gradual migration of std:: standard library precondition violations from exceptions or error codes to contracts. It will also help to remove a majority of all exceptions thrown by the standard library.
3. It will allow the language to consider handling out of memory differently from other errors. The LEWG voted unanimously to pursue section 4.3 of Herb’s paper (P0709) which proposed a path of migrating all OOM from bad_alloc to new(nothrow)-like mechanisms.

   The initial step, not for C++20 mind you, would be to change the default new_handler from throwing bad_alloc to calling terminate.

It’s worth noting that contracts are not permitted to perform an observable modification of an object. It’s also worth adding that this is the first step, for C++20, and the expectation is that the feature will be extended in the future.

Class types in non-type template parameters (p0732)

This change has been desired for a while. This would permit template non-type parameters of user-defined types, and enables instantiation templates with values such as compile-time strings.

Turns out that this is now possible due to a side benefit of the <=> spaceship comparison operator, which was proposed by Herb Sutter.

This is because the semantics of a defaulted <=> comparison is essential, because the compiler has to perform comparisons to determine whether or not the two template instantiations are the same.

Feature test macros (p0941r2)

This allows code to portably test whether certain new features in C++ exist. Now some may wonder “What’s the point of that?” Well, the plan is that it will enable teams to adopt new C++ features before the compilers you use support them.

To use them you’d write something like:

  #if __cpp_hex_float  // feature macro's name

    // modern code here...
  #else
    // do it the old way
  #endif

Once you’ve moved on to the newer compiler, you can drop the #if test and remove the entire #else block. So it ensures that your code is reasonably future proof, and backwards compatible for as long as you need it to be.

One key part of these macros is that these are standardised and can therefore replace a lot of the ‘if gcc version > x or if msvc version > y or if clang version > z’ tests.

Explicit(bool) p0892r2

This is a conditional explicit, along the lines as conditional noexcept. It lets library writers write explicit at a finer granularity, to turn off conversions where possible without having to write two functions at the same time.

When writing a class template which wraps a member of a template parameter type, it’s useful to expose constructors that allow the user to construct the member in place.

STL concepts

The core features of concepts have already been accepted in to C++ 20, however the Evolutionary Working Group had another evening session on Concepts at the meeting in an attempt to resolve the issue of abbreviated function templates (AFTs).

The main issue was that given an AFT written using the Concepts TS syntax, such as (for example):

  void sort(Sortable &s);

it’s not clear that this is a template. And it assumes that you know that Sortable is a concept and not a type.

Two proposals were presented. Herb Sutter presented an in-place syntax proposal (P0745r1) which the previous code sample, would be written:

  void sort (Sortable{} &s);

or

  void (Sortable{S}& s);

The proposal also proposed to change the constrained-parameter syntax to require braces for type parameters so that you’d write instead:

  template<Sortable{S}> void sort(S& s);

The second proposal was Bjarne Stroustrup’s minimal solution to concept syntax problems (p1079r0), which adds a single leading template keyword to announce that an ATF is a template:

  template void sort(Sortable& s);

This proposal leaves the constrained-parameter syntax alone.

Both proposals also have their downsides. Bjarne’s proposal annotates the whole function rather than individual parameters so, for example, if you have a function with multiple parameters, you won’t know at a glance which parameter is a concept. Herb’s proposal changes the constrained-parameter syntax.

Both proposals were well received by the EWG, and there will be further discussions about this in future meetings. However, there is now a new paper in the post meeting mailing, authored by Ville Voutilainen, P1141R0 entitled ‘Yet another approach for constrained declarations’. But this will be discussed in the next report.

Modules

The committee saw a merged approach, which both major proposers said satisfies their requirements, that was met with enthusiasm in the room. The merged proposal (p1103r0) aims to combine the best of the Modules TS and the Atom alternative proposal, which was approved by the EWG.

The merged proposal accomplishes Atom’s goal of providing a better mechanism for existing code bases to transition to Modules via a modularised legacy header. Essentially, existing headers that are not modules but are treated as if they are modules by the compiler. The merged proposal also retains the Modules TS mechanism of global module fragments with some restrictions, such as only allowing #includes and other preprocessor directives in the global module fragment.

It’s noteworthy, however, that the EWG didn’t approve the poll to incorporate a subset of this merged proposal in to C++ 20 at this meeting. But this will be discussed in another meeting.

Graphics

At Jacksonville, the Graphics TS (p0267r8), which was set to contain 2D graphics primitives with a ‘Cairo’ inspired interface, ran in to some controversy. A number of folks had become convinced that, since this was something that professional graphics programmers/game developers were unlikely to use, the time required for a detailed wording review wouldn’t be a good use of committee time.

As a result of this feeling, an evening session was held at the meeting to decide the future of the proposal. Initially, there was no overall consensus on whether or not the committee should proceed with ANY kind of graphics proposal.

Two papers were presented:

• Bruce Adelstein Lelbach presented the Diet Graphics paper (p1062r0), which offered a rebuttal of the need for graphics support in the language but does propose a simple importing API;
• ACCU’s own Guy Davidson also gave a presentation on the current graphics paper (p0267r8) along with some code snippets, and practical demonstrations.

Guy also presented a paper (p0988) which detailed the history of the attempt to bring 2D graphics support into C++. Guy proposed two ways forwards: one was to kill the paper, and the other was to get confirmation that the committee still wanted to bring in 2D graphics support somehow.

This sadly led to no consensus being reached, and thus the graphics TS was abandoned for the time being.

At present it’s my understanding that the BSI are pressing on with publishing the original graphics paper, so while it may not become an ISO standard for 2D graphics, it may become a BSI standard for 2D graphics.

Emyr Williams Emyr Williams is a C++ developer who is on a mission to become a better programmer. His blog can be found at www.becomingbetter.co.uk

Notes: 

More fields may be available via dynamicdata ..