Calling Functions: A Tutorial

by Klaus Iglberger

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.

Asynchronous Stacks and Scopes

by Eric Niebler

In Structured Concurrency, I talk about what structured concurrency is and why it’s a big deal for C++ especially. In this post I discuss some more interesting properties of asynchronous code that is structured: async stacks and async scopes...

The First Big Update of My C++20 Book

by Rainer Grimm

I'm happy to announce the first big update of my C++20 book. The update was mainly due to the improved C++ compiler support of C++20. The update includes concepts, the ranges library, modules, the three-way comparison operator, the format library, and the chrono library.

EDSL Infinity Wars: Mainstreaming Symbolic Computation

by Joel Falcou, Vincent Reverdy

Scientists and Developers want the same thing: a simple code that does exactly what it should. For the former, it implies adhering to their knowledge base and domain idioms. For the latter, it means it compiles in a reasonable time frame and without bugs. for both, it better computes fast in the end. One way developers, especially in C++, provides scientists with usable libraries is to design them as Embedded Domain Specific Languages. Alas, in all honesty, if someone asked the Scientists, they will probably state that LaTex is *the* perfect DSLs they practice every day.

This is an old story and even if we only focus on matrix-based libraries, the current landscape of high-performance computing library -- Blaze, Blitz++, EIGEN, Armadillo, etc... -- is proof that those techniques have a decent public following. This is the point where the icky things start: stories of meta-programming, so-called expression templates and their uphill battle against new C++ features: interaction with auto, rvalue-references, move semantics and so on. The authors have spent quite a bit of their coding life trying to play with or around those techniques and this talk is about what they learned during this journey.

This talk will focus on what kind of mistakes, oversights and traps the old kind of scientific EDSLs fell into. We will investigate why the new C++ features didn't help them but pushed them further into a state of ever-growing complexity. We will present our vision of how a modern-C++ friendly EDSL for science can be built. By starting from scratch, this talk will cover the actual requirements of such a library including move-aware expression templates, symbolic formula building, type/value maps, named parameters and static visitors. As a conclusion, we will scheme over various immediate benefits of such an EDSL and new applications that old style libraries could not handle like symbolic simplification, automatic analytical derivation and more.

Listing of talks for Meeting C++ 2021

by Jens Weller

The conference will feature 29 Talks and 6 AMAs. Talks are 1 hour, AMAs 40 minutes.

The Meeting C++ online job fair returns!

by Jens Weller

The first two online events in remo have been a great success. They've been very well received by the C++ community and this event will now be a part of regularly scheduled events for Meeting C++ online. As remo is not available anymore, the event will be hosted in the new online event platform for Meeting C++ 2021. The event will be again on two days: 21st/22nd September, with the first day being in the afternoon and the second day in the evening...

A Multi-threaded, Transaction-Based Locking Strategy for Containers

by Bob Steagall

With the concurrency tools available in the modern C++ standard library, it is easier than ever to create multi-threaded programs. When we write such applications, there are sometimes cases in which a container simply must be shared among multiple threads. Of course, sharing is trivial if the only operations on the container are reads. In the case where reads greatly outnumber writes, acceptable performance is often attainable with a reader/writer mutex type, like std::shared_mutex. But suppose that the number of writes is similar to, or even greater than, the number of reads -- how does one then perform simultaneous reads and writes on a single container?

One common usage pattern is that, for a given operation, sets of related records are read and updated together. In order to prevent data races and inconsistent views of the data, such sets must be locked together as a unit before any of them can actually be read or updated. Further, it is very easy to accidentally create deadlocks by choosing a seemingly correct locking order. In order to avoid these problems, we would like a locking algorithm that provides three important properties: atomicity, consistency, and isolation.

This talk will describe an algorithm, implemented in C++, that performs such locking based on the concept of strict timestamp ordering. Using only facilities from the C++17 standard library, it employs a straightforward approach to multi-threaded, transactional record locking that requires minimal spatial overhead and yet fulfils the requirements of atomicity, consistency, and isolation. We'll discuss the pros, cons, and limitations of the algorithm, and provide some performance measurements.

Empty Base Class Optimisation, no_unique_address and unique_ptr

by Bartlomiej Filipek

C++20 added a couple of new attributes in the form of [[attrib_name]]. One of them - [[no_unique_address]] - can have surprising effects on the code! In this blog post, you’ll learn how to optimize your classes' layout and make some data members “disappear”. In most cases, it will be just one line of C++20 code.

Let’s go...

Time Travel: Applying Gradual Typing to Time Types with Clang's LibTooling

by Hyrum Wright

Libraries for C++ are constantly evolving, with new APIs being added, old ones being deprecated and functionality continually changing. In past CppCon talks, I've described in abstract how Google manages this change by applying large-scale changes across our C++ codebase using clang's libTooling infrastructure.

In this talk, we'll put this previous work in practice by demonstrating how we use clang-tidy and clang's libTooling library to improve type safety of time types across Google's 250M lines of C++. Using tools currently open sourced as part of clang-tidy, we'll show how the underlying model of time types allow us to migrate from a collection of integers and floating point types to the much more strongly typed `absl::Time` and `absl::Duration` types representing time instants and intervals. Along the way, we'll discover how this process finds existing bugs and prevents new ones from creeping in.

This "gradual typing" technique is not limited to just Time types, and we'll explore how this can be used to improve pointer ownership deduction and other places where more constraining types eliminate classes of bugs.

How to Define Comparison Operators by Default in C++

by Jonathan Boccara

Implementing comparison operators in C++ is easier said than done.

Indeed, for most types, if we could talk to the compiler we would say something like: “to order them, use a lexicographical order on their members”.

But when it comes to writing the corresponding code, things get more complicated.

However, a classical technique using std::tuple makes the code much more concise for comparison operators, and it should be used by default. (At least before C++20, as C++20 made comparison operators even easier to write).

Let’s see the technique involving std::tuple and then how the comparison operators situation evolves with C++20...