CppCon 2024

The sender/receiver framework for asynchronous operations in C++ is well on its way towards standardization in C++26. Previously, the theoretical background and implementation of the framework was shown but there wasn't much detail on how an application using sender/receiver would look like.

This presentation shows how to create a simple HTTP server using the sender/receiver framework with matching networking senders together with a coroutine task and and async scope. The code is created live using fundamental facilities. The goal is to demonstrate that the use of an asynchronous framework doesn't necessarily lead to excessive complexity when using C++'s facilities effectively. The resulting server could be embedded into any application, e.g., to inspect its state or change configurations. The takeaway is that it is reasonably straight forward to create an asynchronous program.

Nowadays, there is one topic that comes up in virtually all discussions on system programming languages: memory safety.
However, even though memory safety rules out many of the most common sources of vulnerabilities, there are still plenty of ways how a vulnerability may find its way into the codebase.

In this talk, we look beyond memory safety and explore how we can prevent vulnerabilities through simple yet effective C++ constructions and custom static analysis scripts.
We analyze multiple examples, from basics like input validation to complex time-of-check vs time-of-use issues when accessing shared resources, all of which are inspired by real-world products, use cases, or vulnerabilities.
For each example, we discuss attacker models, threats, and implementation pitfalls, before looking at potential solutions that are not just secure by themselves but also protect developers from accidentally introducing vulnerabilities in the future.

Attendees will leave with a deeper understanding of security engineering and
inspirations for leveraging C++ to prevent potential security issues by design.

Our C++ code often contains violations of "Don't Repeat Yourself" (DRY). You write down enums, but then you also have to write their stringified version. You write down a class, but you have to expose every method / member in the class separately to be able to bind your class to a Python program (for example).

Reflection is (potentially / hopefully) showing up for C++26, having already been design approved by EWG, its chances are looking promising! This talk will discuss everything the basics of reflection, and we will lead up to three library ideas based on reflection, as a way to understand the massive impact this might have on the kind of libraries our ecosystem can provide, without relying on the core language to provide such abilities. The examples we will go through are:

Automatic python bindings
ABI hashing (hashing a type for efficient compatibility checking)
A better std::any variant type that brings duck typing to C++

Come attend this talk if you'd like to hear about cool new library possibilities that have opened up with reflection!

API design and code performance are some of the most discussed topics in the C++ community. However, surprisingly little is said about the fundamental element of programming where they meet: the function signature. As a result, overhead that can be incurred inside every function body and at every call site is not commonly recognized. Non-inlined function calls are places where the ABI specification comes into play, and its effect on the generated assembly doesn’t always match expectations, even on the common platforms.

In this talk, we’ll bridge the gap and provide a comprehensive list of performance pitfalls to be aware of when designing a function signature, including a compiler’s view on the frequently debated questions:
- returning by value or by output parameter;
- passing parameters by value or by reference;
- using abstractions that are commonly considered to have zero runtime overhead, such as std::unique_ptr and std::span.

One of the most powerful applications of coroutines is in the context of asynchronous operations, where their use allows for significant simplifactions of application code. Unfortunately, building an asynchronous library interface to enable such benefits for applications is not exactly straightforward in C++.

In this talk we will explore the essentials of managing asynchronous control flow with coroutines. We will discover how to reconstruct the call stack of nested asynchronous calls and thus bridge a significant gap between C++'s stackless coroutines and the stackful coroutines from other languages. We will learn how to build a mechanism similar to the async/await from languages like Python or Javascript for our own libraries. And we will explore how we can perform arbitrary manipulations of the call stack in such an environment to unleash the full power of C++'s coroutine mechanism.

At the end of this talk we will have a proper understanding of how the Task<> type found in many coroutine libraries works and how it can be used to manage asynchronous operations. This will serve as an important building block for understanding more advanced mechanisms, like the sender/receiver mechanism proposed for C++26.

This talk assumes basic familiarity with the components of the C++ coroutines language feature: promises, awaitables, coroutine handles, and passing data in and out of coroutines.

This is the second part in an ongoing series of talks about C++20 coroutines.

As much as I like C++, it is certainly not free of -- let's say -- quirks.  Both the core language and the standard library exhibit idiosyncracies, sometimes even in conflict with one another.

Some of these "oops" may be historical in origin.  However, most are due to the spectrum of viewpoints held by the hundreds of contributors who have participated in C++ standardization to date.

This talk points out many of these inconsistencies and numerous other infelicities in naming, behavior, or both.  Come see whether *your* pet C++ peeve is mentioned!