CppCon 2024

This is a session for those interested in visiting the "Deciphering Coroutines" on Thursday. That talk will assume prior familiarity with the C++20 coroutines feature and build heavily on the first "Deciphering Coroutines" talk from CppCon 2022.

If you have not seen the 2022 talk and are not yet familiar with C++20 coroutines, come to this session for a quick recap of the basics. We will do a detailed introduction to coroutines and get you up to speed with everything that you need to know to follow the presentation on Thursday.

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.

Generic programming, better known in C++ as templates, can feel daunting and overwhelming to those unfamiliar with the paradigm.  This Back to Basics talk will explain the foundations of C++ templates, covering the language rules that must be understood in order to work with template code effectively.  I will provide some guidelines for how to use templates and how to write templates.

While you won't come away from this being an expert in template metaprogramming--that's an impossible task for any hour-long presentation--you should have a strong enough foundation that you can correctly maintain template code while you develop your expertise in generic programming over time.

This talk is designed for those who are learning C++ and want an introduction to templates and generic programming.  It will also be useful for experienced C++ developers who haven't mastered templates yet and want to brush up on their understanding of how templates work.

C++20 coroutines present some exciting opportunities for organizing and simplifying concurrent logic, but they have proven challenging to integrate with production systems. Object lifetime and execution order issues can be difficult to manage, especially without guidance from well-established best practices. Practical use requires interoperability with existing event loops and with non-coroutine-aware components. While some experimental libraries have started to be released, the C++ “async ecosystem” is still young compared to many other languages.

We will describe our path through this thicket and introduce Corral, a new open-source concurrency framework for C++ that attempts to tame it. Corral is built around structured concurrency principles, so lifetimes and control flow are easier to reason about. It does not provide any opinionated I/O layer, so it can work with the one you’re already using, or with a standard such as Boost.Asio. We have ported a number of our I/O-bound production processes to use this system, and have found the modernized versions to be substantially simpler with fewer weird bugs.

This talk is geared towards C++ developers who have some familiarity with coroutines but have found them challenging to work with. We will delve into the architectural design of our framework, offering insights that may be useful to others with similar needs. Special emphasis will be placed on practical aspects such as task cancellation, timeouts, and integration with legacy code. We will also share a few design patterns we’ve discovered after two years of production use.

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.

Cppcheck has been evolving for 17 years, guided by a clear philosophy: minimal false positives and ease of use. This presentation will share the insights we've gained during its development. Our approach to easy configuration is a double-edged sword, providing user-friendly setup while occasionally leading to lower recall. We maintain a strict definition of false positives, ensuring the tool does not warn about well-written, functional code. This principle, while challenging, drives us to fix rather than suppress false positives. A core philosophy of Cppcheck is to learn from mistakes. When an issue is identified, we strive to implement checkers to prevent similar mistakes in the future.

The open-source community plays a crucial role in Cppcheck's evolution. We collaborate to enhance the tool, scanning large codebases like Debian's source code to identify inconsistent or dangerous code and measure false positives. We also explore how abstractions, compiler annotations, and contracts can improve SCA tools' precision and performance. This talk will provide a comprehensive look at the lessons learned and the continuous improvement of Cppcheck.

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.

Kris will explain Bitcoin Script, a stack-based scripting language integral to Bitcoin's transaction validation process, Bitcoin Script plays a crucial role in defining custom transaction rules and smart contract functionalities. He will explore the inner workings of Bitcoin Script from a technical standpoint, focusing on its implementation details in C++.

Attendees will gain insights into key concepts such as opcodes, stack operations, and the evaluation engine, as well as security considerations for safe script execution. Additionally, practical use cases will be examined to demonstrate Bitcoin Script's real-world scenarios.

–

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.

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.

Introducing xstd::any<N, Features...>, an extension of C++17’s std::any, designed to be a type-safe, owning container that can handle any data type with enhanced functionality. xstd::any can be configured with additional features such as comparability, hashability, and streamability, making it ready for use in std::map, std::unordered_map, and for output operations. This template-based implementation utilizes small object optimization to store types smaller than N bytes directly, avoiding heap allocation and minimizing dynamic memory overhead.
The presentation will explore the internal design and implementation of xstd::any<>, focusing on how it manages memory efficiently and maintains value semantics even when dynamically allocating larger objects. The session will showcase practical use cases, demonstrate usage with standard C++ containers, and explore the recent C++ features that enhance its functionality.
Like std::variant or std::tuple, xstd::any requires mechanisms to handle various contained object types seamlessly. We will discuss the addition of stream operators, hash functionality, and comparison operators, enhancing its usability across different programming scenarios.

Outline:
* Requirements: Understanding the needs for a versatile container like xstd::any, compared to other generic container types.
* Example Use Cases: Demonstrating practical applications and benefits.
Implementation and Memory Layout: Deep dive into technical details and optimizations.
* Testing: Approaches to ensure reliability and performance.
* Exception Safety: Handling errors and exceptions.
* Interaction with std:: Containers: Integration strategies and examples.
* Question & Answers: Open floor for audience queries and discussions.

Presentation Materials & Source Code: All resources, including detailed presentation slides and the source code, are freely available on GitHub for further exploration and testing.

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.

Concepts are a pretty new key feature of C++. Introduced with C++20, they provide a way to deal with requirements and specify constraints on generic code. This can be used to improve overload resolution, avoid invalid use of generic code, improve error handling, and improve documentation of generic code.

In this talk we introduce the basics of concepts. You will get an overview of
- the difference between requirements, concepts, and constraints
- where you can apply concepts
- how to formulate concepts
- what the standard library gives you as and for concepts
- how to design concepts right

Design by Contract is a very effective approach for writing safer, more correct programs. It has been successfully implemented in programming languages like Eiffel and Ada. Attempts to add a Contracts facility to C++ have a long and storied history spanning two decades. Since the last attempt to standardise Contracts (for the C++20 Standard) has failed, SG21 — the Contracts Study Group on the C++ Standard Committee – has been working on a new design, the so-called Contracts MVP, which is now essentially feature-complete and on track to make it into the upcoming C++26 Standard.

In this talk, we present the current design of the Contracts MVP targeting C++26. We discuss preconditions, postconditions, assertions, contract-violation handling and much more. We consider how the Contracts MVP provides a superior replacement for custom assertion macros and, when used correctly, can significantly improve the safety and correctness of your code.

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.

You must have a certain skill set to write a scripting binding interface for C++ like luabind, sol2, pybind, or ChaiScript. This is a skill set that few seem to posses. But developing this skill set helps you to understand the language in a new, deeper, and more unique way.

We will start from the first principles of what we are trying to accomplish and why. We will then cover the basics of deducing function signatures with templates and the limitations that are hit when you have function overloads. We will wrap these user provided functions with a compile time <-> runtime interface, then demonstrate a simple function dispatch engine.

If we have time, we will then show function reference syntax and how you can use this to bind script engine functions back into the C++ statically typed world.

We will not get to an actual parser for a scripting language. That will be left as an exercise to the viewer.

This talk introduces the Beman Project, a new community initiative to improve the quality of C++ standard library enhancements. The project provides a) a simple way for engineers to evaluate standard library proposal implementations, b) a high quality template for standard library authors to share their implementations, and c) a modern platform for the wider C++ community to discuss standard proposals.

We'll discuss the problems the Beman Project is addressing, how it came about, and, most importantly, how to get involved. At the end of this talk you'll feel equipped to build and test proposed standard libraries, provide feedback, and, perhaps, contribute some implementations yourself!

The Beman Project is named in memory of Beman Dawes, the much loved co-founder of Boost.

This talk examines the use of C++ in building distributed robotic surgical systems, emphasizing safety, performance, and reliability. While C++ offers strong performance benefits, it also presents challenges in meeting industry standards and regulations in the medical technology field. We discuss the architectural decisions and strategies employed to meet international safety standards for medical devices, and present techniques for writing efficient, safe and reliable software. Our experience in building a surgical robotic system serves as a case study, highlighting the challenges and solutions in this highly regulated domain.

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.

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.

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.

Join us, and share your thoughts about CppCon, C++, our field, and our world at our Community Dinner. Together, we are an increasingly diverse and eclectic group and aspire to be more so. Tell us what you want most from your work and from CppCon.

This is a ticketed event, please register to attend by following details here. Registration closes on Sunday, September 15.

Lightning talks are your five minutes of stardom. The format encourages a focused and often high-energy presentation about nearly anything (subject to approval by the conference) that might be interesting to the C++ community, including proprietary technologies. They can be of a lighter or humorous nature, but they need not be.

https://cppcon.org/lightning-talk-submissions/