CppCon 2024

Scott Meyers has famously proclaimed that the most important general design guideline is to make interfaces easy to use correctly and hard to use incorrectly.  I don't dispute that this is one of the most important design guidelines.

However, in my close to 40 years of fighting in the C++ trenches, I'd argue that testability is by far the more important design guideline, and antecedent to both ease of use and performance (a particular C++ penchant).

In this talk, we will discuss what testability means, and why it is so important.  We will briefly discuss some popular testing techniques, but most of our time will be spent looking into items of testability that are rarely discussed, but are extremely important in practice.

The participant will come away with a greater appreciation of the "small" things that are often overlooked in the holistic view of testable designs and implementations.  More importantly, we will all hopefully start asking the single most important question about any part of a software system, big or small:   How are we going to test that?

Debugging asynchronous code is hard; partially because the stack traces that engineers are used to seeing do not provide enough insight to easily determine what went wrong. Often, engineers debug these async bugs by receiving a hint of the issue from the stack trace, going to the source code to read the problematic code, and making educated guesses about the async behavior that could have led to the issue.

But we can do better. In this talk, we introduce async stack trace support, a benefit that becomes possible when adopting coroutines and senders for your asynchronous work. With async stack traces and coroutines, engineers will have visibility into the async call stack leading up to the issue. This was originally developed at Meta in Folly, and we’d like to share this capability so that this could be incorporated into other C++ coroutine libraries and provide a better debugging experience.

Programming normal C++ leads to the use of dynamic memory, pointer chasing, and other issues that zap performance. Because there haven’t been practical solutions to those problems we seldom discuss them, creating the impression that they are unavoidable. Fortunately, the same C++ that binds us frees us to devise techniques centered around the concept of “relocatability” to solve those issues. We will explain what relocatability is and how to achieve it.

Consider the example of runtime polymorphism. You may want to have interfaces and implementations of interfaces. If your object refers to a “polymorphic” member, it normally cannot be implemented as a concrete sub-object, only as a base class pointer that points to a dynamically allocated instance of a derived class. This leads to millions of small objects dispersed throughout memory, all referencing one another. This is already very expensive and other issues around object layout makes things worse. One presenter witnessed 7% of Google Search Qrewrite CPU spent on dealloc, which must chase pointers to finish!

When we want to save the state of such programs, we must traverse those complex object graphs and encode them in complex file formats: serialization is required. Restore is further complicated by needing millions of small allocations which are often ephemeral. In general, working with data architected in this way is error prone and has abysmal performance. Our alternative to these complex object graphs is to lay out program data according to program design objectives, in our case allowing object moves. This is the essence of relocation. The set of techniques we will share with you is complete. Now that we can represent program state as simple, relocatable data, save and restore is simply memory mapping buffers.

For runtime polymorphism, we can use “Type Erasure”, the Design Pattern behind `std::function`, tailored for relocatability. Our Type Erasure performs better than normal polymorphism. We get better performance, we have no allocations, no deallocations, and no pointer chasing; resulting in happier programming. For other issues we get benefits of the same magnitude.

We will explain both well known and novel relocation techniques. The novel techniques have required the formulation of Generic Programming concepts including what we call “Value Manager”. We are presenting these for the first time.

Design patterns are everywhere, as they are the key to managing dependencies between software entities. But despite their fundamental importance, there are some common misconceptions about them, in particular about several of the most often used design patterns:

* The modern form of the Visitor design pattern, std::variant, is often considered a replacement of virtual functions
* The Decorator design pattern is sometimes mistaken as the Adapter design pattern
* The Chain of Responsibility design pattern is often confused with Decorators
* Explicit object parameters (“deducing this”) is often considered as a modern, better form of CRTP

In this talk I'll shed some light on these misconceptions and explain how to properly distinguish between the different design patterns.

It is no secret that managing C++ dependencies is a serious challenge, especially for larger projects. It is consistently cited as a top pain point in ISO C++ developer surveys. The C++ community has been asking for a standard C++ build system and package manager, but we need solutions that we can put into practice today. So, what do we do, especially at larger companies with complex needs? C++ package managers exist and are growing, but there are still many companies hesitant to adopt them.

In this talk I will present what I learned from talking to over 15 large software teams working with C++. Some had already adopted a package manager, many had not. I will go over their challenges with managing C++ dependencies and how they overcame them. The goal is to share some learnings and hopefully generate a discussion in our community about how we can make our development experience less painful.

In an era where cybersecurity threats are ever-evolving, securing C++ applications has never been more critical. This keynote will explore how adopting an adversarial mindset can empower developers to proactively identify and mitigate vulnerabilities. We will delve into common C++ vulnerabilities, the “Rule of Two” security guidelines, and practical strategies for reducing attack surfaces and defending against attack vectors. Additionally, we will discuss recent trends in vulnerabilities, highlight bug bounty costs, and examine real-world examples of vulnerabilities exploited by threat actors. This talk will provide valuable insights into adopting an adversarial mindset and implementing robust security practices in your C++ projects.

A key principle for testing code is the concept of dependency injection aka the ability to swap out functionality of key components. This feature allows not only for easier code testability but also promotes well structured code that is more extensible and flexible beyond its original use cases.

In this talk, we will explore the basic building blocks that can be used for Dependency injection like link-time substitution, dummies, Interfaces via Inheritance, templates and polymorphic function wrappers. What are their strengths and weaknesses and the problem space they best serve.

But what exactly is good dependency injection and what are good/bad strategies for employing these building blocks ?

How do you inject multiple dependencies into classes/functions without going down the road to singletons, factories and global state ? We will also show how to introduce dependency injection into older codebases that were never designed for the concept. Doing this without having to make major changes throughout a legacy codebase ?

After exploring this and other real world use cases, we suggest better ways to handle these specific situations. Finally a coherent strategy for adding DI to your applications should emerge and be added to your developer toolbox.

My talk will examine the internal C++ mechanisms around the topics of:

• The C++ onion as it relates to construction, destruction and polymorphism,
• Order of Object construction & destruction, and pre- & post-main() processing.
• Member Function Pointers (not your father’s C function pointer),
• Member Data Pointers (not raw pointers) (data-morphic functionality),
• Understanding the Call Stack, Stack Frames and Base Pointer mechanisms.

DRY -- don't repeat yourself -- is an important software engineering principle. Repetitive code is error-prone code. Inevitably, and sooner rather than later, we will forget to change one of these repetitive code locations. C++ offers many different tools to share code and data and I often see novice and intermediate programmers struggle with choosing the best one in each situation. We have template functions, template classes, std::variant, virtual classes and std::any. We have some common associated programming patterns like CRTP, templated base classes, template functions taking function arguments. All of these have their uses and in my talk, I want to develop some intuitions on when to use which.

An experience report with tips and tricks for how to make incremental improvements to legacy code and how to prepare C++ code for reuse that has deep dependencies in legacy codebases. We will study real world examples from the merger of three companies all with 20+ year old C++ codebases.

The first part of the talk will cover techniques for making incremental changes to a large legacy C++ codebase. Adopting static analysis and runtime sanitizers, adding test coverage, updating conventions and style, using modern idioms, deprecating and removing legacy code, and fixing undefined behavior all comes with a cost. We will look at practical techniques for making incremental change in these areas without breaking the bank.

In the second part of the talk we will cover the challenges involved with sharing and reusing C++ code from a large legacy codebase and pragmatic techniques for sharing code. Examples will cover easy to extract pieces of code to libraries with deep legacy dependencies. Techniques will range from source code sharing, to hiding behind a DLL boundary, and methods that fall in between.

A key programming principle that encapsulates significant aspects of Object-Oriented Programming, is to hide your implementation details. This guidance aligns with principles such as encapsulation, decoupling, and programming for interfaces rather than concrete types. Yet, keeping your implementation details hidden is no easy feat. In this talk, we'll discuss the challenges, highlight tricky situations, and share tips on how to steer clear of them. Applying the practices presented in this talk, participants will be well-equipped to navigate potential pitfalls, foster best practices, and ultimately write C++ code that is more elegant, robust and maintainable.

We’ve had exceptions in C++ since before the first standard. C++17 introduced std::optional and C++23 std::expected (along with the so-called Monadic Operations for both types).

What should we use and when?

Meanwhile we still have older approaches, such as boolean or error code returns, as well as global or thread local error status or pointer or reference arguments.

Do these still have a place?

And where does assert fit in? And the (hopefully) upcoming contracts?

Perhaps more importantly, once we’ve examined all the trade-offs, can we defer any of those decisions to when we are best positioned to commit to them?

Erroneous conditions can have a big impact on your code’s safety and security, so error handling shouldn’t just be left to the “exercise left for the reader” in the books we used to read. Let’s get this all straight.

The C++ community has long been interested in reflection, and we have made significant progress in adding core reflection capabilities to the language. While there is emerging clarity on the querying side of reflection—inspecting existing code artifacts programmatically—there is considerably less consensus on the generative aspect: using reflection insights to emit new code. As a result, current proposals showcase a stark contrast between well-polished reflection query capabilities and limited code generation capabilities.

Reifying only the reflection of preexisting code in an Ouroboros manner leads to a curious circularity that hinders the synthesis of new artifacts. This talk provides examples that demonstrate the necessity of generative capabilities in reflection and discusses current and upcoming proposals for generative extensions in C++ reflection.

C++ 20 developers do not need to sacrifice high-level expressiveness and code cleanliness for high performance when writing cross-platform code. Concepts and constraints combined with build tool configuration and judicious use of the preprocessor can enable novel techniques resulting in significant improvements to cross-platform architectures. The techniques are the result of experiences in the video games and embedded software fields; however, the techniques are applicable to high performance scientific code and general applications supporting multiple platforms

This presentation discusses how various features of C++ may be used to develop high-level and high-performance code in cross-platform projects. It focuses on the design and implementation of a small family of quaternion classes. Quaternions are a small numeric type used extensively in 3D graphics and thus ideal as the focus. The discussion begins with an unoptimized implementation that will compile on all platforms. Optimized versions for multiple architectures (SSE/AVX, Neon, and WebAssembly SIMD) will be added. These optimized types are added without changing a single line of existing code. Additionally, supporting multiple revisions of a spec will be illustrated. Implementing new revisions does not result in changing any pre-existing files, and new revisions may leverage older revisions and need not ever reimplement pre-existing functions. This reduces code repetition and all its attendant liabilities.

In C++23 we have std::optional and std::expected along with the "monadic" operations that can be used on the objects of these types. By chaining the computations, these abstractions allow you to manipulate the underlying values using less boilerplate code. In addition, we have a range library for processing collections of elements in a similar manner.
These topics have been quite popular in the C++ community for the last five years or so. However, many of them are focused on theoretical parts, have only small non-related examples, or even use other programming languages to illustrate the ideas.
This talk is prepared based on more than one year of using functional programming approaches for developing one of the commercial internal libraries our team is working on. I’m going to share this experience with the audience. We’ll talk about API design in general, spitting between pure and impure context, and the pros and cons of using “optional” and “expected”. There will be real code examples and some useful tips.

This isn't a talk about why you shouldn't use ranges in your C++20 codebase—unless you work on one of the largest codebases in the world, you probably should. This is a talk about the differences between most programming tasks and software engineering at truly gargantuan scales—and about how it isn't always practical to use the same components of a language in such different contexts.

Ranges are perhaps the largest and most ambitious single feature ever added to the C++ standard library since its inception. They have modernized C++ to match the way the current generation of programmers thinks about iteration and loops, largely owing to the influence of dynamically typed languages like Python and Javascript. Every programming language feature comes with a set of trade-offs, though, and it's unreasonable to expect that those trade-offs will result in the same cost-benefit ratio in every context. At Google, the decision to ban the `<ranges>` header from our C++ codebase continues to be extremely controversial, with nuanced arguments on both sides of the discussion. This talk will summarize those arguments, from broad topics like the diffusion of functional programming paradigms in large codebases, to mutability of concept-driven designs over large time scales,  to technical deep-dives on the inner workings of range adapters and the consequences thereof at scale. We'll conclude with a discussion of what this means for the future of ranges and why Google continues to invest in the ranges study group of the C++ committee.

All code is legacy code, or so they say. Software engineers scoff at the idea of new code instantly becoming legacy code, however software is a time capsule holding the design trends of the time the code was written. As new code is written, new design trends are used and potentially overused, just like the legacy patterns. What if these new design trends have more in common with the original design trends than we initially thought. One example we will investigate is object oriented design through polymorphism and how it has been replaced in many cases with template metaprogramming. There are a variety of template metaprogramming strategies that achieve the object oriented design principles, however when overused you can encounter as many templates as there would be virtual functions in object oriented programming. Have we discovered that balance is the solution or are we still overusing the “fancy” new thing? In this talk, we will investigate various legacy design trends including further examining object oriented design, the singleton pattern, as well as other legacy anti-patterns to reveal the updated trends. We will address each legacy anti-pattern and their corresponding modern update to evaluate whether newer is better or if we have recreated the same legacy problem.