Yesterday I came back from my first ever ACCU conference, ACCU 2017, which happened from April 26 to April 29 in Bristol (UK). The experience was simply fantastic - I wholeheartedly recommend attending the conference!

I reinforced my knowledge on many topics and learned new ideas by attending the high-quality talks and keynotes. The schedule was very well chosen and most of the time I found it very hard to choose which talk to see in a slot - that’s a good sign about the quality of the content. Fortunately, all the talks have been professionally recorded and will be available for free on ACCU’s official YouTube channel.

The “social aspect” of the conference was also very important to me. I had a chance to discuss my favorite language over a beer with very smart people that I consider friends, despite the fact we see each other only one or two times per year. I also finally met some active cpplang.slack.com users face to face and made new interesting acquaintances.

The company I currently work for, Bloomberg L.P., was a major sponsor of ACCU 2017 and organized a marvelous event that consisted of a “Chess Armageddon tournament” (where the winner would compete with a grandmaster) and a “live coding DJ” that used Sonic Pi to generate music via code and play it live, accompanied by a guitarist. The event was one of the highlights of the conference for me - I had no expectations but was very pleasantly surprised by the excellent organization, entertainment choices, and unlimited free food/drinks!

I also spoke at the event - my talk was “Implementing variant visitation using lambdas”, which explained how to implement a form of pattern-matching that can be used for variant visitation. Here’s an example:

using my_variant = std::variant<int, float, double>;
my_variant v0{20.f};

// Prints "20f".
match(v0)([](int x)   { cout << x << "i\n"; },
          [](float x) { cout << x << "f\n"; },
          [](double x){ cout << x << "d\n"; });

I’m happy about the way the presentation went and I have received good feedback so far. The video is available here and the slides are available on GitHub at SuperV1234/accu2017.

I’ll share thoughts and lessons learned from some of my favorite talks below.

• Lock-free programming with modern C++ by Timur Doumler.

  Timur’s talk was a thorough and very well-presented introduction to lock-free programming with modern C++. After providing a general explanation of the topic, possible use cases, and related terminology, he discussed std::atomic’s usage and interface in depth. The second half of the talk revolved was my favorite part: Timur showed step-by-step implementations of SPSC (single producer, single consumer) and SPMC (single producer, multiple consumers) lock-free queues. This part of the presentation made obvious how difficult it is to reason about lock-free data structures: in fact, experienced people in the audience pointed out some possible minor mistakes in the implementations which required thinking about very uncommon edge cases. I also asked if there is any way to formally prove the correctness of a lock-free program, and was suggested to research CSP (communicating sequential processes) and process calculus.

  The biggest takeaway from the talk is that (surprise surprise) lock-free programming is extremely hard to get right, and should be avoided unless a very good reason to dive into it exists.

• Atomic’s memory orders, what for? by Frank Birbacher.

  Appropriately scheduled right after Timur’s presentation, this excellent talk consisted of an overview of the C++ memory model and of a thorough explanation of std::memory_order.

  The presentation began with an analogy between the C++ memory model and the concept of “relativity of simultaneity”, which was surprisingly useful. From the first half of the talk, I particularly liked Frank’s explanations of the “happens-before” relation and of the “synchronized-with” relation - these formal relationships are used to describe the memory model in the C++ Standard.

  The presenter’s example-driven explanation of all the various std::memory_order options was really clear to me - I finally understand all the difference between the various semantics (yes, even memory_order_consume), though I still need to reinforce my comprehension of the difference between acq_rel and seq_cst.

  Here are some ASCII diagrams I created to visually remember them.

  // Relaxed semantics: operations can be arbitrarily reordered.
  //
  //          op0             ^
  //           |              | ok
  //           |              |
  foo.store(x, std::memory_order_relaxed);
  //           |              |
  //        ok |              |
  //           v             op1

  // Release semantics: operations appearing before the store cannot
  //                    be reordered after it.
  //
  //          op0             ^
  //           :              | ok
  //           X              |
  foo.store(x, std::memory_order_release);
  //           X              |
  //        no :              |
  //           v             op1

  // Acquire semantics: operations appearing after the load cannot
  //                    be reordered before it.
  //
  //          op0             ^
  //           |              : no
  //           |              X
  foo.load(x, std::memory_order_acquire);
  //           |              X
  //        ok |              :
  //           v             op1

  I highly recommend watching this talk (it’s already available on YouTube) if you’re interested in the subject. Jeff Preshing’s blog is also an amazing resource, containing many illustrated articles (e.g. “acquire and release semantics”) on the memory model and multithreaded/lock-free programming in general.

• C++ Countdown Pub Quiz by Jon Jagger, and Robert Chatley.

  This was not a conventional session… this was an interactive pub quiz inspired by the “Countdown” TV show where small teams of attendees competed with each other over a drink! This session was one of the highlights of the conference for me: it was so much fun!

  In short, every round everyone was given a set of tokens and the goal was to produce the smallest valid C++ program containing all of them. An example is available on the schedule page.

  Everything happened in a customized cyber-dojo instance running g++ 6. Me and @jackayline got very close to winning but got disqualified in the last round - we tried to use the given . token as part of a floating point literal, only to later realize that the entire literal is considered a single token! Still, it was an extremely entertaining session and I really hope to see similar ideas in the future.

• Writing games in very modern C++ by Guy Davidson.

  If you want to learn about the history of video games and want to see a modern C++ clone of “Asteroids” implemented live, this is the talk for you!

  This presentation used an experimental implementation of P0267, which proposed the addition of a modernized version of cairo to the Standard Library. I want to talk about this, because it concerns me and I’m not convinced it’s a good idea.

  Firstly, I think that the scope of “2D graphics API” is way too broad. Some people need high-performance 2D graphics, others need vector graphics, others need something quick for prototyping, others need image manipulation capabilities… and so on. There are good and robust libraries for all of the things I mentioned above (and more). Is standardizing a small API that would be only useful for prototyping or non-performance-intensive applications the right way to go? While it would allow users to quickly display some images/text on the screen, it wouldn’t be a huge improvement from simply including something like SFML or cairo itself. If importing a graphics library in your project is such an hassle that encourages standardization of a library just to avoid the pain, then the real problem is package/dependency management.

  Another worry is the choice of the cairo-like API. I’ve used SFML for a quite a long time, and from what I’ve seen in Guy’s talk, cairo’s API is closer to C and in my opinion inferior to SFML’s. If the committee thinks that a graphics API is a good fit for the Standard Library, I’m sure that something much more powerful and flexible could be proposed. Personally, I would love to see a modernized C++17/20 version of SFML.

  Note that these are only “first impressions” and might not be valid concerns and that I also didn’t spend months working on a proposal for 2D graphics. I may be wrong on this subject but still wanted to voice my concerns and hopefully spark some interesting discussion around P0267.

Coroutines, parallelism, and asynchronous programming were key topics of ACCU 2017.

• Brad Chamberlain’s “The Audacity of Chapel: Scalable Parallel Programming Done Right” keynote covered Chapel, a new programming language for productive and scalable parallel HPC development. I was particularly impressed by the terseness of the language and by its ability to automatically seamlessly achieve parallelism (both via multithreading and through the use of multiple machines) via “domain maps”. I wonder how many of Chapel’s features could be implemented as a C++ library…

• “History of Time: Asynchronous C++” by Steven Simpson demonstrated and benchmarked several ways of implemeting asynchronous network I/O in modern C++, and finally introduced me to epoll. It was interesting to see how simple implementations of a server varied in terms of readability and performance by using different techniques (e.g. poll, epoll, multithreading, callbacks, coroutines).

• Dominic Robinson’s “Coroutines and C++ DSLs for Human Scale Concurrency” showed how the Coroutines TS (and macros) can be (ab)used to implement a safe DSL for actor-based concurrency in modern C++. I found his work very impressive but honestly didn’t understand it very well due to my unfamiliarity with the actor model and languages such as Erlang and Racket which were used as an inspiration for the DSL.

• Concurrency, Parallelism and Coroutines by Anthony Williams was an extremely well-presented overview of the Concurrency, Parallelism, and Coroutines technical specifications, and of the Unified Executors proposal. Anthony also showed how powerful coroutines can be when combined with other features, such as std::experimental::future, which allows continuations through a monadic interface.

The closing keynote by Herb Sutter was simply mindblowing and was I was genuinely happy and excited throughout the presentation. He has been working on some interesting new metaprogramming-related features that I would love to have today and that would elegantly solve a lot of issues. He asked for the recording to not be published until the proposals are presented to the committee, so I won’t discuss any details. Trust me though, it was awesome.