CppCon 2024

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.