CppCon 2024

Jon will share the Bitcoin “origin story,” which is the story of the Cypherpunks and the solution to the Byzantine Generals Problem. He will discuss several real-world problems that the Cypherpunks solved using cryptography, leading up to the development of Bitcoin.

Jon will also cover the three most important use cases of the Bitcoin protocol. The first two use cases, Store of Value and Medium of Exchange, are well-known, but have other, non-Bitcoin solutions. The third use case, Native Internet Money, has a unique solution of great interest to software engineers, particularly in the age of AI.

–

In Eduardo Madrid’s presentation, Bitcoin: From the White Paper to the World's Reserve Currency, scheduled for Tuesday, he will outline the implementation of the Bitcoin protocol based on the Bitcoin White Paper, focusing on how programmable money is possible.

In Kris Jusiak’s presentation, Bitcoin Script: Implementation Details and Use Cases, scheduled for Wednesday, he will present the details which make programmable money possible.

In Eduardo Madrid’s presentation, Role Playing Bitcoin Protocols Including the Lightning Network, scheduled for Thursday, with just an intuitive understanding of Bitcoin Script he will describe the higher abstraction level protocols, such as the Lightning Network.

Join us on Friday for a panel in which Eduardo, Jon, and Kris will answer Bitcoin questions

The Common Package Specification (CPS) is an important initiative to improve the C and C++ tooling ecosystem (and developers life). Last year CppCon2023 talks and discussions have been followed up with continuous work in the specification. This talk advances in the topic by presenting a working implementation of usage of CPS files in Conan C++ package manager and describing the different challenges, approaches and lessons learned in the process.

First, it will be presented how the current package information in ConanCenter allows the automatic creation of CPS files for many tens of thousands of packages for most of the popular C and C++ open source libraries. Even if that is not the end goal and expected flow of the CPS, this can provide an invaluable resource for experimentation and validation of both the specification and tools using it.

Then, the generation and management of CPS files inside packages will be described, including the challenges of managing multiple binary configurations, how to mix them with system-installed packages and how to consume them, both in single and multi-configuration scenarios.

Finally, how the mapping from CPS files to the different build systems (CMake, Meson, Autotools, MSBuild) is implemented via the generation of build-system specific files will be presented.

The talk will conclude with a summary of the lessons learned, open issues and discussion about the future.

"ERROR: RealtimeSanitizer: call to malloc detected during execution of realtime function MyAudioCallback::process!"

"Warning: MyAudioCallback::process must not call blocking fuction ‘SkectchyCall`"

Realtime programmers working on mission-critical audio, autonomous vehicle, and aerospace code are well-acquainted with the golden rule: “Thou shalt not call time-unbounded operations in your realtime thread.” Despite its importance, tools to enforce this rule have been non-existent—until now!

In the latest version of Clang, two new features help uphold realtime guarantees by preventing `malloc`, system calls, and user-defined "unsafe" functions. First, we introduce the Realtime Sanitizer, which detects calls to `malloc`, `pthread_mutex_lock`, and other problematic functions in your realtime code at runtime. Next, we explore the `-Wperf-constraints` system, which provides similar feedback statically at compile time. We will compare and contrast these methods and offer recommendations on how to integrate them into your codebase effectively.

By leveraging these new tools, you can ensure your real-time systems remain robust, reliable, and ready for any challenge.

Efficient memory utilization is a critical aspect of software running in a multi-tenant environment, where resources are shared amongst different processes. Unlike languages with automatic memory management, C++ allows for manual memory management. Developers have control over when memory is allocated and released, which can lead to more efficient resource usage, but also can lead to mistakes causing problems in memory. 

You plugged new code in for a fancy feature and all functional tests were green! You clicked the deploy button, but 10 minutes later an alarm came -- machine memory usage had reached 90%! Things can get even more complicated when you work on a project with numerous contributors. How do you know which of the latest commits resulted in your process eating up all the memory of the OS and never releasing it back?

In this talk, I will try to put together some useful pieces from the real world in order to paint a comprehensive picture from the perspective of a novice C++ developer. By the end of the presentation, you'll have a basic understanding of C++ memory allocation, an awareness of potential memory issues, and the know-how to leverage tools for profiling and analyzing your C++ applications.

Software engineers have an astounding opportunity to benefit from programmable money: now we can program directly with value, introducing the objectivity, auditability, and neutrality of Open Source Code, instead of the opaqueness, ambiguities, biases, and other issues of conventional monetary processes.

Bitcoin is arguably the simplest of all cryptocurrencies, giving us a real opportunity to learn it at this conference. We’ll show examples of money programmability to demonstrate what is truly possible…

In this session, we will leverage our skill as programmers by describing Bitcoin's design as a Software Engineering project, using the white paper as the primary source material with the updates running today ("SegWit", "Taproot", Schnorr Signatures…), aiming to acquire an intuitive understanding of its programming language, Bitcoin Script. Wednesday, you’ll have the opportunity to see the details of Bitcoin Script at Kris Jusiak’s presentation, and on Thursday, we’ll discuss higher abstraction level protocols such as Lightning.

–

In Kris Jusiak’s presentation, Bitcoin Script: Implementation Details and Use Cases, scheduled for Wednesday, he will present the details which make programmable money possible.

In Eduardo Madrid’s presentation, Role Playing Bitcoin Protocols Including the Lightning Network, scheduled for Thursday, with just an intuitive understanding of Bitcoin Script he will describe the higher abstraction level protocols, such as the Lightning Network.

Join us on Friday for a panel in which Eduardo, Jon, and Kris will answer Bitcoin questions.

Most C++ developers are familiar with the type of errors that arise when a shared library is not found. If they are really unlucky, they are have also faced a situation where the the wrong version of a library is loaded. However, a lot of us resort to suboptimal solutions just to get going, without fully addressing the root causes.

A lot of the time, we focus on the “build” process, that is, producing our binaries and executables. But getting the runtime linker/loader to locate the right libraries (and the right versions!) has a unique set of challenges that  should not be overlooked - after all, running the executables is critical for running tests, continuous integration, and obviously end-users running our apps and services.

Managing dependencies continues to be one of the top frustrations of C++ developers as per the most recents ISO C++ Developer Surveys. When it comes to shared libraries - different applications try to locate them at different times: the build system (e.g. CMake or Autotools) when configuring the build, the linker at build time, and the dynamic linker/loader at runtime.

This talk will cover in detail the different scenarios in which shared libraries need to be located, and how this is handled by package managers, build systems, and the the OS level. Emphasis will be placed on familiarizing the developer with the relevant tooling across multiple platforms, as well as associated concepts (e.g. RPATHs).

An often overlooked aspect will also be covered: how to create a self-contained, relocatable bundle for our user-facing applications, decoupled from the developer environment, as opposed to “works on my machine”.

In game development the building and optimisation of data for the game is an important but resource intensive and time consuming process. In this talk I will describe techniques used to improve the performance and efficiency of a data build system that was developed as part of a AAA game project.

I will briefly describe the differences between how the game code and data building code operate, how those differences impact processing performance, how a profiler can be used to identify trouble spots, and describe techniques I used to improve multithreaded processing performance.

While this is coming from a game development perspective the techniques can be applied to any task based parallel data processing system.

This is the story of a design collaboration between a member of our code governance team and a C++ developer leading the effort to update tools that generate C++ code from schema. Through a two year collaboration, we crafted guardrails to a complex system that allowed maximum flexibility to exist alongside common sense restrictions in a single system. We did so successfully thanks to the input and consensus of our huge C++ developer community.

Bloomberg's C++ code generator was created 18 years ago to simplify the task of writing services and code to call those services, freeing up engineers from writing boilerplate code and allowing them to concentrate on writing code that provides business value. The code generator is so popular that it is used beyond services, with hundreds of developers relying on it to also create C++ value semantic types. As a long-lived project, the generator has evolved over the years to support many scenarios and options. While this versatility has been hugely valuable, having so much additional flexibility also created a huge support surface for the tool owners and also burdened users with questions about which options are optimal for their use cases.

Two teams began exploring this problem separately. One focused on updating the code generator while the other looked into how the generator was being used across the company. Progress sped up appreciably when we realized we could combine our expertise in outreach and design. We began a focused conversation with the firm's broader engineering community, which led to key changes to the code generator, the creation of directed CMake modules, the introduction of new rules and validations, and the development of clearer documentation. We put an end to longstanding misunderstandings that had been causing users to make mistakes. Finally, we gave our engineers  a clear outreach path to request new features.


Key takeaways:
* Development and outreach teams working together can make targeted technical improvements to a C++ codebase, and to the developer experience.
* An outreach team can bring existing community relationships, as well as dedicated time, to research larger issues. This gives developers a chance to have a say in designing best practices, in addition to allowing infrastructure teams to make improvements, without bringing other important work to a stop.
* Creating a well-lit path for a tool's usage avoids pressure on developers to craft ad hoc solutions that are unintended and inadequately tested by the tool's creators and maintainers.
* People will do the right thing when everyone involved understands what the right thing should be. Your organization's codebase will benefit.

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.

Writing correct and high-performing IPC (Intra-Process Communication) programs in a constrained environment provides significant challenges. Properly utilizing function interfaces, data types, and ensuring correct data flow are part of the challenge during programming of IPC applications. Furthermore, debugging run-time bugs coming from IPC are some of the hardest and most time-consuming bugs.

We leverage the power of C++20 and concepts to define modern interfaces and constraints, that make IPC programs easy to understand. We introduce a pattern called CCI (Concept, Constraint, and Implementation) to facilitate the creation of modern interfaces encapsulating low-level IPC functions. Therefore, we mitigate numerous pitfalls stemming from IPC programming and prevent run-time bugs.

After explaining CCI and getting a good grounding, we start the re-work of low-level code around CCI. We show how features of C++20 help us utilize CCI. After that, we provide the general assessment of CCI pattern and compare the output of the assembly code regarding the performance.

Birds of a Feather session about growing our GameDev engineering community at conferences.

Small embedded devices might only have one processing core but hardware accelerators, peripherals, and external events abound. Asynchronous event handling is the bread and butter of these systems; however, the lack of robust libraries in the bare-metal arena often result in a concurrency nightmare.

After a short sender/receiver primer, we will explore some patterns and idioms that have proven useful when employing the design in a high availability, complex embedded device. We will use [Intel's open source bare-metal senders and receivers library](https://github.com/intel/cpp-baremetal-senders-and-receivers) as well as other open source packages to build elegant, declarative solutions around interrupt handling, schedulers, devices drivers, and communication protocols. The patterns will be demonstrated on an STM32 target controlling a simple robot.

While this talk is focused on bare-metal implementations and embedded concerns, the shape of a solution is applicable to many domains and environments. Join me as we wrangle concurrency using the sender and receiver design.

Localization in mobile robotics, critical for autonomous navigation, is a challenging problem often addressed through particle filter algorithms, also known as Monte-Carlo Localization (MCL) estimation. The integration of the ranges library in C++20 introduced powerful new tools to enhance the implementation of these algorithms, further extended in C++23. This talk explores the use of these modern C++ features to develop efficient, composable particle filter algorithms that are well-suited for both 2D and 3D localization tasks.

Attendees can expect an introduction to the basics of particle filters, providing a foundation for understanding their application in robotics. They will then be taken through the design and implementation of a series of essential functions for a particle filter library. These examples will demonstrate how C++23 ranges can be used to refactor traditional MCL approaches into more flexible and efficient solutions.

Motion planning algorithms play a crucial role in enabling robot arm to navigate complex environments efficiently. They are required to determine a robot's trajectory and optimize its motion to minimize cycle time and maximize throughput. In this talk, we delve into optimizing a robotic arm motion planner using the CHOMP algorithm, highlighting the significance of employing good coding practices and design patterns.

Beginning with an overview of motion planning techniques and the rationale behind selecting the CHOMP algorithm for robotic arm manipulation, we scrutinize the initial naive code implementation. Transitioning to modern C++ implementation, we introduce key concepts utilized in the refactor and present code snippets illustrating the transformation from legacy to modern paradigms.

Attendees will glean insights into identifying and addressing challenges in legacy code, mastering essential modern C++ concepts for motion planning optimization, and quantifying the tangible benefits through performance metric comparisons. It will further encourage them to integrate design patterns into robotics programs.

C++23 introduced std::mdspan, a multi-dimensional view type that expanded on the capabilities of its predecessors, std::span and std::string_view, by eliminating the restriction to view into contiguous blocks of memory. Multidimensional array-type data structures are commonly used in robotics applications such as RGB and depth images, as well as occupancy grids for navigation. While these alone present a compelling alternative to hand-rolled data structures, this talk will illustrate the flexibility of the layout and accessor policy customization points included in std::mdspan, demonstrating its potential through various examples, including helping a robot arm inventory beer bottles.

This talk will review conventional use cases of std::mdspan in robotics, such as occupancy grids and submaps for determining obstacles and collision checking with polygonal footprints, as well as handling camera images retrieved after deep learning inference. Additionally, we will discuss commanding single and dual robot arms for inventory inspection using synchronous and asynchronous strategies via the std::mdspan accessor policy and std::future.

While these toy examples may have speculative applications, they highlight the flexibility and extensibility of this new data structure for novel use cases.

Session types are the next big thing that will ensure correctness of communication code, and thus make concurrent and distributed software more reliable and easier to construct... at least some people view them that way; although they might also be viewed as just a new weird thing from type theory realm ("functional programming stuff") devised by overly enthusiastic mathematicians, but which is too complicated and cumbersome to be of practical use. Whichever is your own point of view on the line between these two extremes, come to this journey through the first know implementation of session types in C++ if you want: to see the main idea of session types explained in practical programming terms, to understand how and when session types might be useful, or just to enjoy exploring the limits of C++.

The talk targets wider audience, and does not require any strong mathematical background. In the first part, it sets up a working definition of a type, discussing a few different perspectives, and gives a short overview of some models of asynchronous communication. In the second part, an implementation of session types is presented. The implementation is evaluated on an example, and some remaining challenges are described.

Code reflection is an extremely valuable feature for many areas in programming. By allowing you to reason about code as data. Reflection can be used for e.g. Serialization, Networking and content editors.

However, since reflection is not a C++ language feature yet. I will use a new tooling opportunity: ".ifc" Binary Module Interface files to implement a reflection library. Made possible by Gabriel Dos Reis‘s efforts to open source [the specification of MSVC’s Binary Module Interface](https://github.com/microsoft/ifc-spec).

This approach solves issues of current C++ reflection libraries. Which either rely on manual typeinfo registration, leading to constant work to keep them in sync. Or parsing C++ source code which is slow and needs deep integration into your desired build system.

For multiplayer games, deterministic simulations have been a Holy Grail for a long while. Indeed, if we have perfectly deterministic simulations - we can simply pass all the inputs to all the clients, and rely on each client to produce the same results, reducing network traffic by orders of magnitude. While especially important for RTS games, all kinds of multiplayer games would benefit from it.
However, while determinism was achieved in practice for single-platform, it is known to be a next-to-impossible to achieve for cross-platform clients. We will discuss the (well-known) reasons for it first - and will proceed into discussing our approach to the solution (with our open-source lib actually providing some implementations).
This talk is important for multiplayer gamedevs - and for anybody who is interested in deterministic calculations.

Motion planning is a crucial capability for robots operating in unstructured environments, enabling them to navigate and interact with their surroundings safely and efficiently. However, motion planning algorithms are computationally expensive, often requiring hundreds of thousands or millions of evaluations of subroutines, such as forward kinematics, collision checking, and nearest neighbor lookup.

This talk will present an approach to accelerating motion planning subroutines, specifically focusing on forward kinematics calculations, through compile-time optimizations. The proposed method leverages code generation techniques to directly translate Unified Robot Description Format (URDF) into optimized C++ code. Additionally, by generating hardware-specific code, such as CUDA for parallel computations, significant performance gains can be achieved. Throughout the presentation, I will compare and benchmark the compiled URDF to a naive implementation of forward kinematics and evaluate the performance impact of certain design decisions, such as memory layout and compiler flags.

The presentation will demonstrate how the aforementioned code generation process can be seamlessly integrated into the C++ build process using CMake and Jinja templates, enabling easy adoption. Attendees will gain insights into the benefits of compile-time optimizations for performance-critical applications and learn how to leverage this approach to enhance the efficiency of their own robotics or computationally-intensive systems.