CppCon 2024

Safety has been a huge buzzword in the C++ Community in recent years. There are many concerns about the safety of our C++ language, and projects developed using it. Many improvements are being discussed, starting from handling of the low-level fundamental types, through updating the language rules (e.g., initialization), up to providing safer high-level abstractions in the library.

This lecture presents how the usage of a Modern C++ quantities and units library can improve the safety of the code we write every day. During the talk, Mateusz will describe all issues and possible solutions discussed in P2981: Improving our safety with a physical quantities and units library. Based on the examples developed with the mp-units project, the attendees will not only learn the obvious benefits of using such a library but also some less known safety features will be presented.

During the talk, we will see typical issues of code bases that do not use a proper library. We will also learn about various mishaps in engineering that happened through the ages and were caused by human errors in handling quantities and their units. We will also see how they can be easily and safely addressed using the mp-units library.

In the end, Mateusz will describe which issues can't be solved by the quantities and units library itself for now. He will review a list of potential extensions to the C++ language and its library that would allow even more safety in our projects.

As C++ developers, we will have the opportunity to work on many different teams and many different projects throughout our careers. We may sometimes work on a team that’s enjoyable, but isn't delivering too much. Other times, we might work on a team that delivers, but is no fun. If we’re really unlucky, we can end up on a team that doesn’t deliver and isn’t enjoyable. But occasionally, we can have the privilege of being part of a team that not only delivers, but is also a great team to be on.

The ability of us, as individual contributors within a team, to work together effectively is critically important. Often more so in C++ than in many other languages, due to the scale and complexity of the solutions we are often trying to deliver. This ability of individual contributors to work together collaboratively as a team is often not related to their C++ skills and knowledge.

This talk will explore the different characteristics of software development teams, and will look at the different roles and responsibilities within a team. Taking an evidence-based approach, we’ll consider what makes a good team, explore how to encourage more cooperative teamwork in order to achieve better results for everyone on the team, as well as offer some ideas for how to gently improve the teams on which we are currently working.

Heterogeneous containers ("vectors of variants") are an extremely flexible and useful abstraction across many data domains, but std::vector<std::variant<...>> can exhibit extremely bad memory characteristics for mixed types of disparate size, especially if the largest types are relatively uncommon in practice. Variants always have to be at least as large as their largest contained type, and vector implicitly requires all of its members to be the same size, leading to significant bloat in such cases. Motivated by real-world use-cases, this talk explores the design of a bit-packed replacement data structure that can achieve massive improvements in memory usage, and the impacts that these optimizations have on its API.

Clang's compilation database specification has been a way for tools to understand what is happening within a build. It has been used to drive language server protocols for editor/IDE integration, facilitate static analysis over codebases, and more. Alas, it is not powerful enough to properly describe a build that includes C++ modules. Something more is needed: a build database.

In this talk, I'll explore the limitations of the compilation database when it comes to modules, why modules require further enhancement, and plans in the works to generate the additional information needed to understand how the build of a codebase using C++ modules really works.

If you've ever struggled to write tests for domain-specific functions with complicated, real-world inputs, this talk is for you!  We'll use the Motion Planning component in a self-driving stack as a case study (although you won't need any prior Motion Planning experience to follow the talk).  In building objects for our test inputs, we faced the classic dilemma.  If we make the objects simple, they're hardly meaningful, and the tests amount to little more than smoke tests.  If we try constructing more realistic objects, it takes tremendous amounts of boilerplate code (which obscures what is actually being tested) --- and what's worse, these finicky construction methods go stale and break easily as implementation details evolve.

There is a better way!  To find it, we take our inspiration from a (paraphrased) Kent Beck quote: "First, make the test easy.  (Warning: this may be hard!)  Then, write the easy test."  What this means is investing in full-fledged testing support libraries.  First, we build foundational domain-specific APIs: user-friendly paths, poses, and speed profiles.  Then, we provide APIs that bridge the gap between what the user pictures in their head when they want to write a test (a "scene"), and the data structures that represent that situation in the software (a sequence of planner input messages on different channels).  This "scene description" that the user writes is high level and doesn't depend on implementation details, so it resists going stale, as we'll illustrate with an example involving road construction zones.  On the implementation side, the problem decomposes beautifully: each planner input (map, actors, etc.) can be constructed from the information in the scene description, independently of all other inputs, helped along by the paths and speed profiles.

These ideas could be implemented in many languages, but C++ particularly excels at delivering performance, robustness, and flexible, natural APIs.  As an example, we'll explain the benefits of describing each planner input with a "smart" tag type, containing both the name and the message type.  On the implementation side, variadic templates make it easy to conjure up containers and interfaces that operate on "all planner inputs", eliminating the risk of forgetting to update some callsite when we add a new one.  On the interface side, end users see none of this complexity: they can simply use _instances_ of these tag types as "indexes" into these containers in a natural way.  This fluency and power makes more complicated test cases possible: it becomes easy to select and "tweak" any planner input to ensure we respond correctly when the messages are malformed, delayed, or absent.  Overall, we hope our experience enabling high-quality Motion Planning testing at scale will have lessons that can be adapted to a variety of other domains.