it++ 2019

In Italy, June is usually that period of the year when the weather becomes hot and the Italian C++ conference is held in Milan.

That’s why (the conference, not the weather) on Saturday 15th June, my friend and coworker Francesco and I went to the Milan Polytechnic. As for the other conferences I attended, I wrote quite a large volume of notes. Regretfully, as it happened for the other conferences, reorganizing my notes to make some sense of them and present them in an understandable and useful way is out of reach for my homeopathic level of free time. Also, usually you can find online the slides and videos of the talks well before my post. Therefore I decided for the short format I already used a couple of times in the past – a brief overview describing the conference for what you can’t see in the video e a brief summary of the talks I attended to.

This is the third installment of the C++ conference. It is worth noting that the conference is free (as in beer) and that the promoters and organizers are enthusiast volunteers. It++ is held on Saturday, I guess on purpose, to let everyone interested in C++, and not just those working as programmers with employers willing to let them go to conferences, to attend.

Since last year participants increased from 240 to 310, while sponsors decreased from 10 to 7. That’s peculiar – interest in C++ seems to raise in people and to wash away from companies. More on this quite below.

A very interesting conference wrap up has been published by Marco Arena.

Demographics

C++ conferences tend to have people of all ages – you can meet freshmen and even high school boys and white-haired (or bald) men in their fifties. In this sense, C++ seems to be much more cross-generational than other programming languages (I can only speak for Scala and functional languages) whose conferences are mainly attended by young people.

Despite non-discrimination and equal opportunities, women were statistically not there – you could have counted them on a single hand (maybe two, but not more). The increasing interest for computers from ladies is not reflected in the C++ community as much as it is in the Scala community – at least if national conferences are any indicator.

Stands

Four sponsors had their desks outside the rooms where the talks were given –

• Conan – the C++ build system
• Jet Brains – the company behind CLion IDE
• KDab – consultancy for Qt and C++
• Develer – embedded system consultant company

One big difference with Lambda World and Scala Days (and only partially with Scala Italy) is that companies at stands just wanted to sell services/products, while in other conferences many companies were also looking for people to hire.

I find Conan really interesting. Their goal is to be for C++ what Maven (and Mavencentral) is for Java (and other JVM languages). Not an easy task considering how fragmented the C++ universe is – different operating systems, different compilers, incompatible APIs, different build tools, different directory layouts, different everything.

Jet Brains is also a top-quality vendor for IDE. Their CLion is a great IDE for C++ rivaling, in terms of quality with Microsoft Visual Studio (not Visual Studio Code). At work we also use IntelliJ that is the same IDE targeted at Scala. People at the stand promised us that a Clion version supporting embedded target debugging with J-Link was about to be released. That would be the final missing bit to rule the embedded world development on Linux.

Location and Food

The location choosen this year has a special meaning to me, since Politecnico di Milano is the University where I studied and spent endless hours in engineering classes. It was magic then, it is magic now, at least to me.

The two classrooms were adequate in size and comfort (a power socket was available every two seats). The day was quite hot so the air conditioning was a welcome addition. One negative note is worth making about the audio system, especially when driven by radio microphones – speech was muffled and barely audible.

Food and beverages – served in the cloister – were plenty and high quality on par or even better than other paid conferences I attended to.

Toilettes were somewhat hidden and given their state maybe this was not that unintended, but hey, this is a school, you know how students behave :-). Anyway not conference organizers’ fault nor something they could have done anything about.

Tracks

The conference was organized in two parallel tracks, with a few common speeches.

In the Welcome Message – the lead organizer Marco Arena, introduced the conference, speaking about attendance trends, sponsorship, location and so on. I really appreciate Marco’s energy and enthusiasm. Setting up events like this is not an easy or light task and he’s doing great on his free time.

Key Note – “Allegro” Means Both Fast and Happy. Coincidence?

by Andrei Alexandrescu. Video Slides.

The Key Note was held by the renowned programmer and book, book author Andrei Alexandrescu. His speech has been entertaining and thought-provoking. After a brief and funny presentation, Andrei started talking about optimization and sorting algorithm. His point was that algorithm textbooks could be very well outdated since hardware architecture improved so much in the last decades. For this reason, when trying to squeeze the last clock cycle from your CPU, just relying on past knowledge may be misleading.

Aside from some memorable quotes (SESE is crap, all loops must be while(true), every programmer must write a sort algorithm), all the presentation focused on the small details to steal the last CPU cycle from a single core. It leaves me wonder if the C++ is retreating to the niche of “scale down” optimization, leaving the rest of the world “scale up” optimization. I mean that JVM languages offer scalability by ramping up the number of elaboration nodes. While C++ has no ISO standard support for clustering, but allows you to exploit up to the last cycle of the single core.

Concepts in C++20 a Revolution

by Rainer Grimm, video slides

In the other track The joys and trials of writing cross-platform C++ code, let the tools help by Marc Goodner, video slides

This choice was quite easy, I’ve been written cross-platform C and C++ code for quite a while now, while concepts are a new entry to the C++ world. Well, “new” may not be the most accurate description, since the idea had been considered since the early versions of the standards (c++11), but never made it through the committee.

Concepts are a way to set constraints on template types so that a) type checking is easier and b) error messages can be more meaningful and concise. This construct is inspired to Haskell type classes (I found it interesting that a purely functional language some 20 years ago was where C++ want to be tomorrow).

Concepts do not seem too hard to use. You can define yours in quite a straightforward way via the concept keyword and by a set of functions that defines the required interface.

One of my favourite quote is “it’s never too late to do the right thing”, let’s just hope that they don’t stop now.

Vector++ 17

by Davide Bianchi, video slides

In the other track Optimizing the Optimizer, link time and profile guided optimization by Nicolò Valigi, video slides.

Davide Bianchi works at UbiSoft so we could have been coworkers (well not in this Ubiverse, maybe in another one where Ubi wouldn’t lay off its Italian programming team in 2004, but this is meat for another post). I used mainly this criteria (and the suggestion of my friend Francesco) to pick vector++ talk.

Vector++ is a library for vector math, where “vector” is the math concept usually represented by a pointed arrow and not the std::vector container from the C++ standard library.

I didn’t enjoy this talk – the speaker took too much info for granted and the description of the library was just too partial and fragmented. E.g. his definition for swizzlers – a concept he talked for some minutes – was like this “If you don’t know what “swizzlers” are there is a good presentation by Valentin Galea“. Also, I had the impression that he was afraid to disclose too much and gave away just parts of his library keeping key points secret. Maybe it was just the bad audio and the hunger (this was the last talk of the morning). Anyway, I couldn’t find the library on the web and the slides contain no details about the implementation of, say, swizzlers.

Bonus talk

AIV (Accademia Italiana Videogame) held a speech during the lunch break. Well, lunch break is a somewhat holy time when attendees are expected to network (which was quite hard since no wifi password was given) and eat to and beyond what their legs could carry around.

For these reasons it was unconceivable for me to attend AIV speech… In reality I got distracted by the buffet and forgot about the talk.

The Future of C++ with modules

by Dmitry Kozhevnikov, video slides

The other track was “ABI Compatibility is not a Major Problem” by Javier Garcia Sogo – video slides here, here and here.

This choice was a no brainer as well – of course I want to know about the future of my language of choice and understand how the standard committee dealt with the coexistance between modules and #includes.

Now that the preprocessor powered #include mechanism to implement modularity is a sort of ancient dinosaurus, I think it is clear to many. The preprocessor does not understand the syntax and the semantic of the language. Moreover you need an additional mechanism to define symbols to export when you are forging a library.

Four issues are the main concerns about the #include mechanism that modules attempt to solve –
1) Huge number of lines included even for trivial programs (e.g. 30kLoc for hello world)
2) header files do not identify a scope, this require additional coding to prevent leaking (if possible at all).
3) Thanks to preprocessor magic, ODR can be violated (e.g. by defining some symbol before including a file).
4) Accidental dependencies may be hidden by order of inclusion.

Modules are accessed by the keyword import which loads pre-processed code. The standard does not mandate anything regard to import and namespace and to module hierarchy. You can use dots in module names, but there is not specific meaning associated.

Also the standard does not define binary module interface (BMI) nor mandate anything. So it is up to compiler vendors to maintain BMI. Therefore binary distribution can work only in a limited and controlled context.

Modules seems like a half hearted feature – they cohexist with traditional #include TU. It seems that modules are not thought as a solid way to promote integration, but just as a weak alternative to includes. Moreover modules make the computation of depdendecies harder, and they are likely to increase compile time.

Sometimes it seems so hard for the standard committee to do the right thing, or at least to copy from other languages. Instead, it is like the committee took the “failure is not an option” to a new level, not allowing itself to take a timely decision even if not optimal. So good ideas like modules get mumbled and chewed on forever resulting in unconvinced and weak solutions. Other examples? Filesystem, futures, GUI, concepts…

Coroutines in practice

by Alberto Barbati, video slides.

Alternative track was “Custom tooling for frameworks libraries and projects using Clang, getting Clazy” by James Turner / video no slides available (yet).

I picked Alberto’s presentation. Ideally, this is the second half of the presentation he held last year at it++2018. In this talk Alberto presented how to implement your own coroutines by leveraging the C++ standard language support.

The example used was two coroutines communicating over a pipe. Unfortunately, there was a lot of meat and it would have been helpful to refresh the content of his previous speech in order to get this one entirely. I liked how coroutines and futures interact, but I am still not sure how much work is still on programmers’ shoulder in order to get this example running. (The source code is available here so the answer would not be so hard to get, I’m just lazy).

ECS back and forth

by Michele Caini, video slides

No choice for the last talk of the day, since the other speaker was not present. ECS – Entity Component System is an architectural design that distinguishes data and code (as opposed to what is preached by OO) and groups together data in linear structures.
This is very suitable for gaming where game entities may have several components, that could be hard to model with inheritance relationship.
The talk had been interesting, but really not related to C++ – ECS was presented with no language support and every architecture description could have been implemented in any programming language.

My Thoughts

In my reflections, I’d like to distinguish two aspects – the conference and the language. The conference has been very good, as I wrote above, the quality has been on par, or even better, of paid conferences. A wealth of kudos goes to the organizers who did this in their spare time just for the sake of their passion with C++ and their desire to serve the community. International level speakers, a wide assortment of topics and even two tracks to chose from, gorgeous buffets. Really you couldn’t ask more for the price. The low audio quality and the lack of an open wifi connection were not their faults, that was what the hosting location offered.

On the language side, I’m still not convinced that C++ is evolving at a proper pace in the proper direction. When comparing it to other programming languages free from a standard committee you can’t fail to notice that those languages are progressing and experimenting with sound constructs, while C++ is lagging behind often with a confusing or partial solution. Take the filesystem component – Java had it from the start back in 1996; Python, rust, go, even C! I mean, each of these languages was able to deal with filesystem objects (files and directories) and using a dictionary belonging to the language paradigm. In C++ not only until C++17 you couldn’t manipulate file paths without writing platform-dependent code, but you had to mess around with char* and std::string to get the work done.

But even when C++ gets to the point where competitor languages are, the work often seems half done.
Take std::optional and std::future – they can be used in the functional paradigm by the useful concept of monad. But C++ seems to miss this point even if since C++11 is providing functional tools.
Take the lambda functions – when compared to other languages, C++ syntax is cumbersome and overly complex. I see no problem to rewrite the following lambda –

[]( auto x ){ return x % 2 == 0; }

as

[] x => x % 2

(and even the capture lambda introducer [] could be omitted, with a suitable parser).

As of today the main field of application for C++ seems to be energy-efficient computing. Aside from C there are not that many competitors, at least until rust gains enough moment.