Telescopes and matrices and audio: Kona trip report

A little “me” time

It really does take quite a long time to traverse ten time zones. From Heathrow to Kona via Seattle is quite a trial in an aeroplane, no matter how luxurious. I attended the Kona C++ committee meeting through the benevolence of a private sponsor on the committee and the C++ foundation and, since I was going to be making the journey anyway, I decided to take a few extra days before the committee started to get over some fierce jet lag and look at the island.

I hired a car and over two days drove right around the island, visiting black sand beaches, the Southernmost point of the United States and the Mauna Kea visitor centre: ascending the summit to see the telescopes requires a 4×4 vehicle.

Of course, I wasn’t going to let that stop me and, on Sunday, with a few other committee members, I hired a 4×4 and we ascended Mauna Kea. It is a climb of 4200 metres, which we managed in about two hours, all the while worrying about altitude-sickness-induced recklessness. The drive is challenging, with some rather precipitous drops to gaze over as you slowly climb. It is an other-worldly place, above the clouds and coloured like a Martian landscape. We had to keep stopping so that we could go “wow!” at the extraordinary scenery and take photos.

As we stopped and parked among the telescopes, wandering from building to building, we realised that there was probably plenty of C++ code executing behind the doors of the observatories. We are never far from our trade.

During the descent I seemed to lose my voice, through shouting how amazing it all was at everyone in the car, and also my hearing, as I failed to equalise the pressure in my head. It seems that America and I may not be destined to enjoy harmonious times together (see Jacksonville). Nonetheless, I enjoyed the universes’s sense of irony that, in the week I would be discussing an audio paper, I was deprived of my sound I/O faculties.

Committee rooms

This was the final meeting for advancing new features to C++20. Proposals advanced to Core and Library from this meeting would be put in the wording queue with the hope of being reviewed and moved to the standard before publication. There is already an excellent report on reddit summarising the work by Bryce Adelstein Lelbach and others, so I won’t duplicate that here.

I wasn’t at the committee meeting in San Diego, so I was unfamiliar with the new Study Groups EWG-I and LEWG-I, the incubators for language evolution and library evolution. I spent most of my time in LEWG and LEWG-I considering what was trying to make its way into the C++ standard library.

I really enjoyed my time in LEWG-I. Proposals were brought for direction review or design review, and experienced library people kicked the metaphorical tyres and offered extensive advice. I imagine this will improve the process in LEWG as many obvious kinks will have been ironed out before proposals reach that point. Of course, this won’t speed up the wording review process in LWG: this doesn’t per se increase our paper bandwidth.

One of the first papers I saw in LEWG-I was P1433, Hana Dusíková’s proposal for Compile Time Regular Expressions (CTRE). Hana has been speaking about this at conferences since CppCon 2017. I am really looking forward to seeing this progress to the library, and volunteered to assist with the paper. LEWG-I also assisted with review on the two papers I am co-authoring: more details below.

Given how close we were to the deadline, I was expecting an abundance of caution from LEWG in voting stuff on to LWG in case it was a little undercooked, but perhaps I was being optimistic. The desire to get a feature into C++20 rather than waiting for another cycle (THREE WHOLE YEARS! NEARLY A LIFETIME!) may have tempered any hesitancy. There is also a new place to be careful, and that is with concepts. Once a concept is voted in, it can’t be changed: code that relies on a concept can’t have that contract narrowed or widened. Concepts are both constraining and satisfying.

Linear algebra

With two papers in flight, I didn’t spend as much time in committee rooms as usual. The first of these was P1385, a proposal to add linear algebra support to the C++ standard library. I have spoken about this at Meeting C++, an Avast meetup and C++ On Sea. This proposal has its origins in the 2D Graphics proposal: after presenting that at Jacksonville in 2018 to a somewhat hostile audience, Bob Steagall approached me to suggest that we collaborate on a separate linear algebra proposal; this is the result.

On day two of committee, an evening session was held to present the paper to interested parties. On day three we had a session in LEWG-I where we received some first class feedback from other authors of linear algebra libraries, mathematicians and engineers. On the morning of day five, SG6, SG14 and SG19 gave it a good look in a joint session. My co-author did all the talking as my voice was still in a rather broken state. It was quite dizzying but very gratifying to hear so much support for the idea and approach. In a nutshell, the proposal offers some client types (matrix, row_vector, column_vector) and a large selection of customisation options to enable the creation of the optimum specialisation for your use-case. Do read the paper: we are open to all feedback. Take a look at the straw man implementation on Bob’s repository. Star it if you like it.

I was astonished at the level of interest. Although as a mathematician it is obvious to me how fundamentally important it is for C++ to know about linear algebra, I was not expecting so many people to follow the paper so keenly. I hope that this will simply be the first of many papers. Succession papers may specialise the interface for domains like machine learning, geometry and so on. By laying the foundation, by way of providing fundamental types, I hope that linear algebra users will be able to easily write code that is comprehensible by all C++ programmers.

Audio

At the end of 2017 I watched a CppCon video by Guy Somberg about audio. Guy is a significant contributor to game audio programming, and at the end of his talk he wondered if there was scope for std::audio. I approached him via email and we started discussion over monthly teleconferences. I also asked Timur Doumler to give a non-game perspective, and we spent much of 2018 putting it together. I’ve taken a more organisational role with this paper, having found two people with considerably greater expertise than mine, but nonetheless our aims are aligned: to provide a way to record and playback audio in a standard fashion.

We first presented our efforts at ADC in November 2018 to a warm reception (note that I am at PEAK BEARD at this point, so forgive the appearance of a mad wizard; note also that the first time we met in real life was ten minutes prior to the start of this talk). This encouraged us in our efforts and we were pleased to present P1386 to the committee, particularly to LEWG-I and SG13. Impressively, Timur defended the paper almost single-handed for four hours. Again, we received some first class feedback, particularly from JF Bastien and Jeffrey Yasskin amongst others. We hope to have something significant to present at the next committee at Cologne as a result. The advance of coroutines actually simplifies things considerably, as does mdspan. Meanwhile, you can take a look at the implementation on our repository. Star it if you like it. Also, take a look at Timur’s trip report for some additional detail.

Bryce has done a great job of chairing LEWG-I and I want to thank him for the time he allocated to our papers. The quality of design input can’t be overstated and it makes a tremendous difference to our trajectory. I strongly recommend that if you have a library paper you target LEWG-I before you target LEWG.

HMI (Human-Machine Interface)

There is an overarching concern running through these papers. Devoted readers will recall that after Rapperswil an unconventional direction was chosen to continue the development of the 2D Graphics proposal. Since then, I wrote another paper defending the proposal, as a result of which SG13 was reanimated to consider the proposal, saving the committee from dealing with an external TS.

Note that SG13 is devoted to HMI, not just 2D graphics. The group’s remit is to consider all proposals related to user interaction, which means we are looking for work on audio and controllers as well.

This is a thorny subject for the committee. There are those who think the standard library should be as small as possible, while others (such as myself) have a more maximalist approach. Getting beyond the console, std::cout and std::cin, is a steep learning curve, and a standard HMI approach would help in this matter. Of course, standardising something as stable as recording and playing audio, as well as collecting controller input and returning haptic feedback, is a rather different undertaking from attempting to standardise 2D I/O.

There seems to be a division between server and client developers. Developers working on the server side don’t care for HMI, while developers on the client side live or die by good HMI. I do wonder how this circle might be squared in the coming years. With the large feature drop for C++20 out of the way, I hope that some consideration will be given to this matter during the next cycle.

What’s next

Proposals that made it through the evolution groups aren’t guaranteed to be present in C++20, since the wording review takes time, of which we have a finite amount. The next meeting in Cologne is going to be important for seeing what can be processed from that queue, and for confirming the content of the next standard.

However, we now have a pretty good idea of what C++20 will look like, and it looks like being the biggest change to the language since C++11. I imagine it won’t be long before people start saying C++2.0 and I wouldn’t blame them: since C++17 we have added concepts, contracts, ranges, coroutines and modules. These will all change the way we write C++, and change what C++ looks like. I’m particularly looking forward to seeing how coroutines will change how we read code.

My prediction for the next cycle is that it will be dominated by reflection, metaclasses, executors and networking. However, I also hope that we will start to consider the HMI question. Additionally, audio requires me to redouble my efforts to reanimate the ring buffer proposal, P0059.

I’ll be speaking about Linear Algebra at Using C++ in Madrid on Thursday March 7th, and also at 4Developers in Warsaw on Monday April 8th. I’ll also be at ACCU in Bristol from Wednesday April 10th. Stop me and ask about HMI!

Leave a Reply

Your email address will not be published. Required fields are marked *