CppCon 2020

If the all_of() track is full, then join us in generate_n() as the overflow room.


Often, we focus on novel, clever, and advanced features of C++. To contrast, here I look at addressing relatively simple problems in relatively simple ways under severe constraints of performance, ease of use, and reliability. My main example is to read and write typed objects from and to a byte buffer. This is of course something we do a lot and in a bewildering variety of ways. Any object that needs to be stored or transmitted to another computer must go through such a process. However, the constrains on such reading and writing varies immensely based on the kind of data to be moved around, the performance and reliability requirements, the hardware available, and history. Many trade-offs are possible, and many different interfaces. That makes this an interesting design exercise.

This is an exploration of a design space close to the hardware and of the use of C++ in that space, rather than a standards proposal or the presentation of a mature tool chain. And, no, by “primitive”, I don’t mean “old-fashioned, C-like” code; some of the general techniques are old, but some of the code requires C++17 and much could be done better given features we are unlikely to get even in C++23.

SOLID is an abbreviation for five of the most important software design principles:

- (S)ingle Responsibility Principle
- (O)pen-Closed Principle
- (L)iskov Substitution Principle
- (I)nterface Segregation Principle
- (D)ependency Inversion Principle

For almost two decades, these principles have proven to be a valuable set of guidelines to cope with software dependencies. Although initially introduced as guidelines for object-oriented programming, they have become a universal set of guidelines that can be used equally well for procedural, functional or generic programming. In this talk I'll recap the SOLID principles and explain why they form such a valuable set of universal design guidelines. Also, I'll go into detail about several common misconceptions.

How is a function call resolved? How does the compiler find the right function and how does the compiler choose from a set of available functions? This talk will give an overview of the individual steps taken during the resolution of a function call. It will primarily focus on the different kinds of name lookup, argument deduction, and on overload resolution. Attendees will gain insight into the mechanics of (un-)qualified lookup, argument dependent lookup, two-phase lookup, name hiding, SFINAE, (viable) candiate functions, and ambiguous function calls. They will leave the talk with a much better understanding of the (sometimes surprising) details of function calls.

Writing standard-compliant iterators is surprisingly easy to get wrong. Standard containers are tedious to write, because they have such large interfaces, involving lots of similar operations. For many years, Boost.Iterator's iterator_facade and iterator_adaptor were the state of the art for automating the creation of iterators with minimal effort. However, that library has not kept up with the evolution of C++, particularly with regard to constexpr and noexcept.

Boost.STLInterfaces is a newly-accepted Boost library that solves these problems for authors of iterators and sequence containers. It does this using the same approach as C++20's std::ranges::view_interface. The view_interface template is a CRTP base that implements all the possible view member functions when inherited by a derived type containing just begin() and end(). This pattern allows the user to use Boost.STLInterfaces to write correct iterators, views, and/or sequence containers, requiring surprisingly little code.

Join Zach Laine for a hallway-style discussion on:

• STL algorithms 
• STL containers
• Unicode ⌘

On CppCon 2019, Mateusz provided an overview of current solutions on the market as well as the challenges of implementing a modern C++ physical units library. This year's talk will focus on 'mp-units', the library developed by Mateusz and contributors, and proposed for the C++ standardization.

During this tutorial, we will get familiar with the building blocks of the library's framework and its most important concepts. Numerous code examples will present how to use and solve real-life problems with the library. The audience will learn how easy it is to extend it with new units, dimensions, or even whole new systems of quantities. Last but not least, Mateusz will provide a brief overview of how well this library performs compared to other products on the market.

Even if you are not interested in the physical units subject itself, you might still want to attend the talk as the library is full of C++20 features.

Join Mateusz Pusz for a hallway-style discussion on:

• Modern C++
• Templates, metaprogramming
• C++20
• the C++ standardization process
• Performance and Low Latency
• Delivering online talks and workshops
• CMake
• Conan

If the all_of() track is full, then join us in generate_n() as the overflow room.


The technical work on C++20 was finished in January 2020, and is now being pushed through ISO certification.

This presentation gives an overview of (almost) all new features in both the language and the Standard Library. Some more exotic features will be left out. New language features include modules, coroutines, concepts, templated lambdas, constexpr changes, designated initializers, the spaceship operator, string literals as template parameters, feature test macros, conditional explicit, immediate functions, and more.

The second part of the session discusses the changes to the Standard Library. This includes topics such as ranges, atomic smart pointers, cancellable threads, a synchronization library, calendars, time zones, span, a formatting library, features test macros, and more.

The material is mostly the same as the "C++20: What's in it for you?" session from CppCon 2019, but it has been updated with the final standard. If you want a complete overview of all C++20 features, including references to other more deep-dive sessions at CppCon 2020 on certain topics, then this session is for you.

A job system is a common game engine component to improve total CPU throughput. In this talk, I will walk through building a coroutine-based job system and explain the advantages of using coroutines over the typical ways to build a job system.

We shipped coroutines in C++20, but why does it matter for users, especially since there’s no standard library support? The answer is the coroutine semantics. Developers can customize the behavior of `co_return`, `co_yield`, `co_await` to build their own systems without any dependency of the standard library. For game developers, this is important because many game studios forbid the use of the standard library. The coroutine language feature itself is flexible enough to build a system with 100% control, which is exactly what engine developers want—no black box, no magic.

I will discuss the design decision I made, trade-offs, and current limitations. This talk is a crash course for system developers who want to build systems independently from the standard library and will also discuss possible future directions for this language feature.

This is an advanced coroutine talk and I expect attendees to have basic understanding about how (c++)coroutine works. Here is a useful link for some related materials if you want more information before attending this talk: https://gist.github.com/MattPD/9b55db49537a90545a90447392ad3aeb

Join Tanki Zhang for a hallway-style discussion on:

• Game and Game Engine Development
• Computer Graphics
• General C++

At CppCon 2019, Microsoft open-sourced its implementation of the C++ Standard Library. In the year since then, we've worked with many contributors on GitHub, adding dozens of C++20 features. In this talk, we'll explore some of these C++20 features and how you can use them in your code (even if you don't use our implementation). We'll also take a tour of microsoft/STL development on GitHub and our intensive code review process.

Examples of C++20 features we'll explore: span which makes working with contiguous sequences easier, constexpr algorithms which make it possible to verify that lookup tables are sorted at compile time (or just sort them at compile time!), erase_if() which finally supersedes the "erase-remove idiom", integer comparison functions which make it easier to write correct code without worrying about the Usual Arithmetic Conversions, and make_shared() for arrays which extends the classic "single allocation" optimization.

We're using GitHub issues and pull requests for all development, and we're recording a detailed Changelog in a GitHub wiki page. If you want to follow our progress, this talk will explain how to find what we're working on and what remains to be done. This talk will also show how we use a GitHub project to track PRs as they go through multiple stages of review. (The span PR accumulated almost 700 comments before being merged!) If you're interested in contributing, whether it's a small improvement or an entire feature, seeing this process should help.

Our mission at ViewRay's is to conquer cancer by reenvisioning radiation therapy

Part of this is a piece of software which supports many workflows involving communication with various external agents such as an MRI scanner, a radiotherapy linear accelerator, a database, and, of course, the human operator. This software was started from scratch at the beginning of 2019 and is developed primarily in C++17.

This talk covers the multi-threaded and multi-process architecture of the software. It focuses on one of its elements: immutable objects. This is a pattern which started with functional programming. It was popularized by Haskell and it's hugely popular in web development — the React-Redux stack, for example — but it is not that popular in C++ software development. We will talk about how we ended up sticking with immutable objects, how they helped (and sometimes hindered) our development, what we invented in order to make them practical in C++, and problems and solutions we encountered along the way.

If the all_of() track is full, then join us in generate_n() as the overflow room.


Performance is one of the chief reasons why many C++ programmers love the language. In the past, Moore's Law meant that our programs ran faster every year. Now that Dennard scaling has ended, C++ programmers have to work harder to get high performance for their applications. In this talk, I'll first discuss some of the significant and surprising challenges facing C++ programmers trying to achieve high performance on modern hardware platforms: performance is far less stable and predictable than you might think! I'll present some experimental evidence that strongly suggests we can't count on compiler optimizations to help us out of this hole: in particular, I'll show -- using a new experimental methodology -- that the difference between clang's -O2 and -O3 optimization levels is essentially indistinguishable from noise.

Since compiler optimizations have run out of steam, we need better profiling support, especially for modern concurrent, multi-threaded applications. I'll talk about a new approach to profiling, which I call "causal profiling". Causal profiling lets programmers optimize for throughput or latency, and which pinpoints and accurately predicts the impact of optimizations. It works by running performance experiments, based on the idea of "virtual speedups". We've built a causal profiler called Coz, which now ships as part of standard Linux distros, and which also works for C++ and Rust (there's even a Java version). Using it, we find that Coz can unlock previously unknown optimization opportunities. Guided by Coz, we improved the performance of Memcached (9%), SQLite (25%), and accelerated six other applications by as much as 68%; in most cases, this involved modifying less than 10 lines of code and took under half an hour (without any prior understanding of the programs!).

C++ cross-platform development is difficult. These difficulties are compounded by the fractured solution field, where every project seems to use a different combination of build systems, package managers, and diagnostic tools to address shared challenges. Join us for a discussion and demo of C++ cross-platform development centered on common pitfalls and widely adopted tooling.

Learn how to leverage CMake to seamlessly build across operating systems and platforms. Untangle your dependencies with tools like vcpkg and Conan to avoid inconsistencies between system package managers. Debug your projects across multiple platforms with Visual Studio and Visual Studio Code. We’ll also take a brief look into how to use CI and testing to get in front of issues before they even happen.

The rise of remote work and the growth of team sizes present a challenge for C++ developers. Many C++ projects have complex hardware and software requirements, making onboarding of new team members and productive coding from home harder than they need to be. We need tools to ease configuration of your team's development environments and grant them access to the processing power they need from wherever they are in the world.

This presentation will show how Codespaces can use the power and flexibility of the cloud to address these issues. Codespaces give you the ability to quickly create a managed online development environment specific to your project that you can access from anywhere. We'll look at the problems which hit C++ developers particularly hard, like long build times and dependency management. Finally, we'll show the tool in action to give you a feel for how your teams could leverage it, and more broadly get you to think about what parts of your team's development process can be streamlined.

C++17 already has parallel algorithms.  Executors (P0443, hopefully in C++23) will add asynchronous execution to parallelism.  The usual C++ error handling approach, exceptions, will not work "out of the box."  We need to build up new patterns for error handling.

C++ parallel algorithms and executors have several challenges handling errors.  First, errors can happen nonlocally -- in parallel tasks other than my own -- yet they can affect correctness of an entire parallel algorithm.  Second, notification of errors may be deferred: I may not find out about an error right away.  Third, I may need to take explicit action to find out about an error.  Fourth, checking whether an error has occurred somewhere might have a performance cost.  Finally, letting exceptions propagate across certain boundaries may have unfortunate consequences: the program might crash without respecting destructors and stack unwinding, or it might even "hang" (become unresponsive).

I'm not offering canned solutions to these issues.  However, we don't have to start from scratch: this situation shares much in common with others that have been around for decades.  Examples include non-C++ interfaces to C++ libraries, boundaries between graphical user interface and back-end code, and distributed-memory parallel code.  My experience is mainly with distributed-memory parallel code that uses MPI, the Message Passing Interface that has seen nearly 30 years of continuous use and evolution.  In this talk, I'll show how design patterns already exist for parallel error handling, and I'll apply these design patterns to C++17 parallel algorithms, executors (P0443r13), and parallel algorithms for executors (P1897r3).

Mark Hoemmen has been developing parallel libraries and applications for over a decade.

He is working with others on a linear algebra library for the C++ Standard.

What is C++ Pub Quiz, you ask? It's trivia night CppCon style — five rounds, ten questions per round. Write down your team’s answers on a sheet of paper and turn it in at the end of the round.

Remo's "table" system seems ideal for this, so here's the deal: We'll meet in this event's Remo room at the scheduled time. Join a table near the front of the room with whoever you want to be on your team; turn on your mic in Remo. In the Remo general chat, I'll post a Google Meet URL and a Google Form URL. Open the Google Meet in a second tab; turn off your mic in Google Meet.

Each team should pick a team name, and designate a "team captain" who will use the Google Form to submit their answer sheet at the end of each round.

I'll read each round's questions into the Google Meet. (You will be listening in the Google Meet; or, you might designate a "team communications officer" who will be in the Meet with their mic off and their speakers on, relaying the audio through to everyone at their Remo table. Either way should work.) During the round, feel free to converse with your teammates around the table. At the end of the round, the "team captain" will submit your answer sheet via the Google Form, and we'll have a short break while I tally the scores.

High score after five rounds wins both the game and the bragging rights!

Are you a C++ community leader? Would you like to be?

If you are or would like to be working to build a C++ community, either on-line or in meat space, we'd like to hear from you about your challenges and your successes.

We'll hear from successful community leaders, answer questions, and share resources and ideas. We'll discuss user groups, conferences, podcast, and online communities and forums.

If it weren't for names, we would all be programming in a machine language of zeroes and ones.

C++ gives us an incredibly rich collection of language features for declaring and accessing names and their associated program artifacts. For example, C++ has several kinds of id-expressions (not just names), several kinds of scopes (not just blocks and namespaces), several kinds of declarations, and a plethora of name lookup algorithms (some with several variations).

This talk will provide deeper insights into what these language features do, how they interact, and how we programmers can take best advantage of them. Using numerous examples, we will touch upon such related topics as friendship and hidden friends, hiding and overriding, inline namespaces, labels, overloading, points of declaration, using-declarations and using-directives, visibility, and more.

If the all_of() track is full, then join us in generate_n() as the overflow room.


Our most detailed reasoning about programs is done locally: we consider a neighborhood of a program — usually a single function and the interfaces surrounding it — and reason about its behavior without reference to the remainder of the program. But this reasoning is in service of a larger goal: we want to ensure that the entire program behaves correctly.

In this talk, I will take local reasoning for granted, and look at the process of joining neighborhoods of local reasoning together, and the global reasoning that ensures they form a coherent whole. I will show how we can prevent incoherent joining, and prevent the emergence of unbounded non-local recursion as the program is linked together.

This talk builds upon the discussion of local reasoning in last year's talk "The Truth of a Procedure,” but is intended to be understandable independently.

Among the many new additions to C++20 are Ranges, a modern revision of the STL offering updated algorithms and new “views” with lazy evaluation.

In this example-based talk we’ll work through several practical demonstrations of how the new Ranges functionality may be used to solve everyday problems concisely, elegantly and efficiently. In addition, we’ll offer tips on how to avoid common errors in your Ranges code, and demonstrate a couple of useful utility functions which you can drop into your codebase today.

Forget factories, singletons, and proxies; What are the real patterns in software development? This talk explores abstract mathematical structures that commonly recur in software development. Once a mind is trained to recognize these patterns, it becomes easy to identify the fundamental operations for domain specific classes and how to put the pieces together. This discussion is for those who enjoy math, abstract concepts, and expanding their minds.

The Pub Quiz so nice, we're doing it twice! A new batch of questions for a new evening. You're welcome to join us no matter whether you attended Wednesday evening's session or not. You're encouraged to mix up the existing teams and choose new team names. Teams are also encouraged to leave an empty chair at their table; you never know who might drop in during the game!

What is C++ Pub Quiz, you ask? It's trivia night CppCon style — five rounds, ten questions per round. Write down your team’s answers on a sheet of paper and turn it in at the end of the round.

Remo's "table" system seems ideal for this, so here's the deal: We'll meet in this event's Remo room at the scheduled time. Join a table near the front of the room with whoever you want to be on your team; turn on your mic in Remo. In the Remo general chat, I'll post a Google Meet URL and a Google Form URL. Open the Google Meet in a second tab; turn off your mic in Google Meet.

Each team should pick a team name, and designate a "team captain" who will use the Google Form to submit their answer sheet at the end of each round.

I'll read each round's questions into the Google Meet. (You will be listening in the Google Meet; or, you might designate a "team communications officer" who will be in the Meet with their mic off and their speakers on, relaying the audio through to everyone at their Remo table. Either way should work.) During the round, feel free to converse with your teammates around the table. At the end of the round, the "team captain" will submit your answer sheet via the Google Form, and we'll have a short break while I tally the scores.

High score after five rounds wins both the game and the bragging rights!

Halide is an open-source, domain-specific language for optimizing image processing, machine learning, and general array processing. It is used by major companies like Google, Adobe, and Qualcomm to optimize performance-critical software. It processes every photo taken with a Pixel phone, composites layers in every Photoshop document, and handles video processing at scale at YouTube.

We will explore how Halide achieves top-tier performance in a fraction of the development time by separating the algorithm (what to compute) from the schedule (how to optimize it). Halide's schedules determine trade-offs between parallelism, vectorization, cache locality, and memory management in a simple, modular way. Programmers can easily target different CPUs and GPUs by writing multiple schedules. Halide integrates tightly with C++ and provides both a JIT and a C++ compatible ahead-of-time compiler.

In this laptop I will use to talk to you, std::function is measured to have, for normal use cases, a latency overhead of over 79% for dispatching compared to just using function pointers. Our colleagues at Facebook improve in folly::Function by over 14%, however the open source Zoo libraries’ implementations I will talk to you about improves upon folly’s at least another 24% (35% over libc++) while at the same time dramatically reducing the object code size and allowing lots of practical features being proposed for what Arthur O’Dwyer calls “the design space of std::function“, all with top performance. When I report these findings colleagues have a hard time believing them, the presumption is by this time we should know well how to implement this with nearly theoretical maximum performance; then I must be wrong, my implementation has got to be severely flawed in some way... yet this library is used extensively in a mobile app that has over 200 million daily active users, in Android, iOS, and Windows, Mac OS X apps.

The improvements come from performance oversights that indeed have lasted for decades, once I tell you what they are, together with simple yet rigorous benchmarks and compiler explorer links, you will have no trouble to understand the improvements and realizing there are general principles we could learn from. That’s what this presentation is about.

Improving std::function is just the tip of the iceberg, when it comes to dispatching to behavior specified at runtime, there are many performance mistakes concerning the design of callbacks, event subscription/publishing mechanisms, and even the very language supports runtime polymorphism in a way that is very hostile to performance, among other problems. I hope to tell you all about the solutions we have found for these problems in the presentation “Type Erasing The Pains Of Runtime Polymorphism”, here we will focus exclusively on attaining nearly maximal performance while dispatching to runtime specified user code.

The techniques to be discussed are not processor architecture specific but general, directly applicable to components such as std::function, std::variant, their hybrids, throwing exceptions, error handling, the visitor design pattern, and the whole of runtime polymorphism. Furthermore, the examples are from real life improvements.

The facilities of the Networking TS provide a framework within which testable, extensible, asynchronous programs may be written in C++. Alongside this the Networking TS provides concrete “I/O object” types which provide means of performing I/O and thereby allow the authoring of such programs immediately.

Invariably these provided I/O objects will not be sufficient. Datagram and stream sockets do not describe the entire universe of asynchronous I/O. When the time comes to author new I/O objects it will be important to do so within the framework of the Networking TS thereby providing facilities ripe for reuse and composition.

The talk will explore the task of authoring new I/O object types by motivating and illustrating the facilities and patterns the Networking TS provides for this purpose.

If the all_of() track is full, then join us in generate_n() as the overflow room.


We often hear “C++ is more complex than it needs to be,” typically demonstrated using anecdotes and “gotcha” examples. Those can be valid and demonstrate real pain points, but it would be nice to have more quantifiable data that we could analyze to measure sources of complexity. This talk reports work to systematically catalog and measure C++’s unneeded complexity, how some current evolution proposals may address its major sources, and presents specific suggestions on what we might be able to do about it in the context of a future-evolution proposal to simplify parameter passing and provide meaningful initialization guarantees in C++.