CppCon 2024

This is an exciting year for ISO C++: In just the past few months, it has started to become clear that C++ is approaching three major positive turning points that are starting to materialize together in a blossoming of usability we haven’t seen since C++11.


First, compile-time reflection, including source generation, will dominate the next decade of C++ as arguably the most powerful feature that we’ve ever standardized, and (fingers crossed!) it’s on track for being included in C++26 in the coming months. I expect reflection’s impact on library building to be comparable to that of all the other library-building improvements combined that we’ve added since C++98.

• Related: The CppCon 2024 Friday keynote will be all about reflection… more about that will be announced soon!

Second, memory safety is being taken seriously in WG21. After a decade or two of gradual smaller improvements, the committee is actively working toward taking the major step of enabling well-known proven-effective safety checks at compile time by default, without compromising performance.

• Related: The CppCon 2024 Monday evening panel and Wednesday keynote will be all about safety… more about those will be announced soon!

Third, simplifying C++ is being taken seriously. I’m not the only person actively proposing simplifications to C++, and I expect the rate of simplification proposal papers to increase again in the coming year as the fruits of in-the-field experiments turn into evidence that the experimental improvements are working and are ready to be considered for ISO C++ itself to benefit all programmers.

Most of all, the above overlap and reinforce each other. For example, reflection will enable writing more new facilities as compile-time libraries instead of as language features that have to be baked into a compiler, which helps simplify future language evolution. Reflection will also enable compile-time libraries that let developers express their intent directly and leave it to the library code to accurately generate correct implementations, which helps reduce errors and makes our code both simpler and safer.

ISO C++ has long been solidly in the top 5 programming languages and is going strong. This talk presents reasons to expect that C++’s future is bright, and that perhaps its most important decade is just ahead.

Come join the conference photo, taken directly outside Adams. Be part of conference history!

Photo will be taken by CppCon's official conference photographer, Jonathan Phillips.

The sender/receiver framework for asynchronous operations in C++ is well on its way towards standardization in C++26. Previously, the theoretical background and implementation of the framework was shown but there wasn't much detail on how an application using sender/receiver would look like.

This presentation shows how to create a simple HTTP server using the sender/receiver framework with matching networking senders together with a coroutine task and and async scope. The code is created live using fundamental facilities. The goal is to demonstrate that the use of an asynchronous framework doesn't necessarily lead to excessive complexity when using C++'s facilities effectively. The resulting server could be embedded into any application, e.g., to inspect its state or change configurations. The takeaway is that it is reasonably straight forward to create an asynchronous program.

Nowadays, there is one topic that comes up in virtually all discussions on system programming languages: memory safety.
However, even though memory safety rules out many of the most common sources of vulnerabilities, there are still plenty of ways how a vulnerability may find its way into the codebase.

In this talk, we look beyond memory safety and explore how we can prevent vulnerabilities through simple yet effective C++ constructions and custom static analysis scripts.
We analyze multiple examples, from basics like input validation to complex time-of-check vs time-of-use issues when accessing shared resources, all of which are inspired by real-world products, use cases, or vulnerabilities.
For each example, we discuss attacker models, threats, and implementation pitfalls, before looking at potential solutions that are not just secure by themselves but also protect developers from accidentally introducing vulnerabilities in the future.

Attendees will leave with a deeper understanding of security engineering and
inspirations for leveraging C++ to prevent potential security issues by design.

Unit Testing is a big, complicated subject. With good advice coming in from books, conference talks, and blog posts beyond count, it's a daunting topic even for experienced developers.  Can we make the subject more approachable?

Yes we can.  If we look a little deeper, there are some fundamental principles behind the advice. Further, these principles seem to belong to a small number of "domains", each addressing a very different aspect of unit testing and software development.

For example, "Test error conditions separately", "Tests should be easy to read", and "Write the unit tests first" are all great advice, but each is aiming for a very different goal.

In this talk, we'll survey these domains of unit testing practice, identify some of the basic practices involved in each, and put the larger discussion of unit testing into a more useful context.  We will also see how some unit testing practices enhance or conflict with others, and how these controversies reveal deep philosophical questions that have real consequences for how we go about the day-to-day activity of testing our code.

Using the volatile keyword correctly is vital when accessing hardware devices in C++. Unfortunately, the volatile keyword is among the most misunderstood aspects of the language. If you don’t use volatile appropriately, you may find the compiler generating code that’s very different from what you intended.

This session will help you write more robust device drivers that avoid common mistakes surrounding volatile. Step by step, it explains:

 
• Why volatile is necessary

 
• How volatile affects the code that the compiler generates

 
• How you should place volatile in object declarations

 
• Which statements the compiler is and isn’t allowed to reorder around accesses to volatile objects

 
• How to avoid misusing volatile

 
• How to avoid introducing inefficiencies when using volatile objects

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

This session is an informal “BoF + show-and-tell” meetup for people interested in Cpp2/cppfront.
Here are some ideas:
- Do you have a pull request you're working on? Show it off and get feedback
- Chat in person about some of the GitHub cppfront Discussion topics
- Other related topics welcome!
- Last year Herb used this meeting as a chance to run some informal polls

Perhaps you've heard that you should reduce variable scope. But have you ever really stopped to think about why? In this session we'll run through a manufactured example that illustrates the difference reducing variable scope can make, and we'll do some examination as to what difference it made with the compiler.

Hashing is crucial for efficient data retrieval and storage. This presentation delves into computing hashes for aggregated user-defined types and experimenting with various hash algorithms. We will explore the essentials of hash functions and their properties, techniques for hashing complex user-defined types, and customizing std::hash for specialized needs. 
   Additionally, we (re)introduce a framework for experimenting with and benchmarking different hash algorithms. This will allow easy switching of hashing algorithms used by complex data structures, enabling easy comparisons. Hash algorithm designers can concentrate on designing better hash algorithms, with little worry about how these new algorithms can be incorporated into existing code. Type designers can create their hash support just once, without worrying about what hashing algorithm should be used. 
   You will gain practical insights and tools to implement, customize, and evaluate hash functions in C++, enhancing software performance and reliability.

If you've attended any talks about concurrency, you've no doubt heard the term "lock-free programming" or "lock-free algorithms". Usually these talks will give you a slide that explains vaguely what this means, but you accept that is is approximately (but not quite exactly) equal to "just don't use locks". More formally, lock-freedom is about guaranteeing how much progress your algorithm will make in a given time. Specifically, a lock-free algorithm will always make *some* progress on at least one operation/thread. It does not guarantee however that *all threads* make progress. In a lock-free algorithm, a particular operation can still be blocked for an arbitrary long time because of the actions of other contending threads. What can we do in situations where this is unacceptable, such as when we want to guarantee low latency for every operation on our data structure rather than just low average latency?

In these situations, there is a stronger progress guarantee that we can aim for called *wait-freedom*. An algorithm is wait free if *every* operation is guaranteed to make progress in a bounded amount of time, i.e., no thread can ever be blocked for an arbitrarily long time. This helps to guarantee low tail latency for all operations, rather than low average latency in which some operations are left behind. In this talk, we will give an introduction to designing and implementing wait-free algorithms.

Without assuming too much background of the audience, we will review the core ideas of lock-free programming and understand the classic techniques for transforming a blocking algorithm into a lock-free one. The main bread-and-butter technique for lock-free algorithms is the *compare-exchange loop* or "CAS loop", in which an operation reads the current state of the data structure, creates some sort of updated version, and then attempts to install the update via a compare-exchange, looping until it succeeds. compare-exchange loops suffer under high contention since the success of one operation will often cause another to have to repeat work until they succeed. The bread-and-butter technique of wait-free programming that overcomes this issue is *helping*. When operations contend, instead of racing to see who wins, an operation that encounters another already-in-progress operation attempts to help it complete first, then proceeds with its own operation. This results in the initial operation succeeding instead of being clobbered and forced to try again.

Are you a fresh face in the world of C++ development, or perhaps you've got a bit of experience under your belt? Have you ever stopped to marvel at just how often std::vector pops up? It's a thing of beauty, a structure you can just keep piling data into, effortlessly sort, search, insert, and delete from. But do you know the price you pay for all this convenience? What about when you need to expand the structure? Or when you're on the hunt for something specific? Ever dabbled with custom predicates to dynamically tweak your data? With a plethora of data structures at our disposal in the standard library, it's a head-scratcher why std::vector seems to steal the show.

Join this talk to unravel the mystery behind why we almost always opt for std::vector, and learn how to wield it with maximum efficiency.

Message reception and dispatch is something common to many codebases. And deep down, we know that Boolean algebra underlies everything we do. But we seldom give it a second thought, or if we do, we probably dismiss it as trivial; something we learned in college and quickly outgrew.

This talk shows the unreasonable effectiveness of going back to basics and really understanding and unlocking the power of Boolean algebra in the design of a message handling library for embedded systems. We’ll talk about separating message layout and semantics, how to match against messages for dispatch, and particularly how to compose and simplify constraints at compile time, in order to do the least at runtime. We’ll also introduce Boolean implication and see a non-obvious application which is key to a generic approach. Finally we’ll see how message matchers can be generically transformed using compile-time information, allowing complete flexibility of expression and maximum runtime performance.

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.

Our game programmers and game engines involve fights between heroes and their foes. There are «classical», traditional ways to express heroes and monsters fighting each other, but contemporary C++ is particularly expressive and versatile language and with out language there are many ways for heroes and monsters to hit at each other. These techniques are what this talk will explore

Learn what Return Value Optimization (RVO) is, and what you can do to ensure the compiler applies it on your C++ code! This talk is open to beginner, intermediate, and advanced C++ audiences, and will be especially valuable for engineers who work on large-scale and/or high performance codebases.

While this compiler optimization technique was first added into the C++ Standard way back in 1997, many of today’s engineers have forgotten to utilize it in their production-deployed code.

This talk will dive into different perspectives as to what RVO is, including how copy elision is defined in the C++ Standard, as well as an analysis of Assembly when RVO is enabled. We will cover the different types of RVO, compiler support for it, and guidelines to help programmers ensure that the compiler uses RVO on their code. These guidelines will tie into examples from real-world scenarios where engineers could have optimized their code to gain the time and space benefits that come with RVO. We will also showcase the performance improvements that come from employing this compiler optimization technique.

This talk presents a series of effective patterns to address challenges arising when
code is developed that shall operate seamlessly on both GPU (Cuda) and CPU environments.
This scenario is a common oversight among Cuda developers,
given the substantial architectural differences between CPUs and GPUs.

The patterns presented cover a range of scenarios,
from handling stray function calls,
strategies for conditional compilation,
exploiting constexpr functions,
leveraging undefined behaviour,
usage of Cuda specific macros,
conditional instantiation of templates,
and
managing compiler warnings and errors.

Key patterns include: "Host device everything", "Conditional function body", "Constexpr everything", "Disable the warnings", "Defensive Programming", "Conditional Host Device Template", and "Function dispatching".

We evaluate each pattern based on ease of use, maintenance overhead, applicability and known usages. Additionally, pitfalls to avoid and considerations for implementations are provided to guide developers in adopting these patterns effectively.

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?

"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.

If you're interested in high-performance computing, this talk is for you! This talk aims to revolutionise how you think about the performance of associative operations.

Associative iteration is a powerful technique that allows for efficient computation of associative operations (addition, multiplication, and other monoids) in `O(log(N))` time as opposed to `O(N)` time.

The name for this technique was coined by my collaborators, and it is my goal to share their insights about it.

Associative Iteration is an absurdly general technique that leverages the properties of associativity that when combined with parallelism can achieve outstanding performance with very little effort.

We define Associative Iteration (unrelated to "iterators" as you might expect) as the repeated application of some associative operation with respect to a "count", some explicit number of operations. This technique applies generally to all monoids, so whether you're concatenating string, multiplying matrices, or simply adding integers, this talk will be useful to you!

Furthermore any "divide and conquer" algorithm that can be represented using this method should achieve near optimal or optimal performance.

This talk will specifically introduce a templated function that allows you to leverage the power of Associative Iteration in a way specific to parallelism.

Task-based concurrency offers benefits in streamlining software and enhancing overall responsiveness. Numerous frameworks build upon this approach by furnishing abstractions that harness the capabilities of modern multi-core processors and distributed computing environments. These frameworks achieve this by facilitating the creation of task graphs, which simplify the management of task execution order and dependencies between tasks.

However, these frameworks are typically not well suited for use in low latency environments where every nanosecond matters, and any additional overhead introduced by managing task graphs can impact the system's ability to meet stringent latency requirements.

This presentation introduces Work Contracts, a novel approach specifically tailored for low-latency environments, which re-imagines both task-based concurrency as well as tasks themselves. We present an innovative lock free, often wait free, data structure designed to significantly enhance scalability in parallel task distribution, particularly under high contention.  Additionally, we introduce concepts which enhance tasks with internal state allowing for single threaded or parallel execution, recurring execution, and deterministic asynchronous task destruction. 

Finally, we examine usage cases for Work Contracts to showcase the advantages that this solution makes possible, resulting in cleaner, more manageable, and more scalable software which is well suited for low latency applications.

Functions are the fundamental unit of interoperability in software design: users write applications by composing functions provided by various libraries. However, naive function composition can result in poor performance due to memory overheads that exist at function boundaries. Operator fusion --- combining the execution of several operators into one operator --- is a well-known technique to combat this overhead. Previous solutions to add fusion rely on complex, monolithic compilers and languages that force performance engineers to rediscover old solutions in new ecosystems, leading to decades of performance engineering work going underutilized. In this work, I attempt to identify the minimal ingredients required to enable fusion on top of existing library interfaces. In doing so, I propose a lightweight enrichment of function interfaces that exposes data production and consumption patterns of functions. I show how to implement these ideas in C++ and demonstrate the benefits of my system by showing that it is competitive with state-of-the-art high-performance libraries, and that it can fuse across library boundaries for unforeseen workloads.

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.

HRT is excited to be back at CppCon again this year! We invite you to attend our Networking Social on Monday, September 16th, at 6:30PM MT. Come grab drinks, snacks, and swag on us - space is limited, so please RSVP through this link by Sunday, September 15th. All are invited, but those who RSVP in advance will receive expedited entry.

Interested in opportunities at HRT?
Software Engineers create and maintain critical technology and infrastructure at HRT. Their work spans our incredible live trading system and a powerful research environment; Software Engineers bring deep knowledge of C++, OS internals, CPU architecture, and networking hardware and protocols.
We’re offering CppCon attendees a priority application review - feel free to use this special link.

If you’re interested in any other roles, check out our careers website or email maytal@hudson-trading.com. We have opportunities available in New York, Chicago, Austin, Boulder, and our international offices.

Looking forward to seeing you all!

When it comes to security, using "good" randomness is key - at least so we are told. But unlike using an insecure protocol or a weak cryptographic key, it may not be intuitive why "bad" randomness may be a problem. What even makes randomness "good" or "bad"?

In this session we will explore several real-world exploits based on bad randomness including online poker, cryptocurrencies, cars, web-traffic encryption, and video games.
Don't worry, no security background knowledge needed.

In the end, you will have entertaining stories to share and a better and more intuitive understanding of the dangers of "bad" randomness.

Since our first popular Safety and Security panel at CppCon 2023, there has been a lot of development in ISO C++ in this space and in this panel we aim to give everyone a chance to ask the key authors questions on this development. There has been development in:

1. Profiles P2687r0 , P2816R0 , and P3038R0,: what is the main idea?

2. C++ Core Guidelines Concurrency and Parallelism sections: how will this improve C++ safety

3. MISRA C++ 2023 published based on C++ 17: what does it contain?

4. Contracts: how close are we? Will it be in 26?

5. SG23 Safety and Security and SG21 contracts

6. Safety/Security Blog post by Herb Sutter

Recent US government reports and media follow-ups have been numerous:

https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/

https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf

https://www.infoworld.com/article/3713203/white-house-urges-developers-to-dump-c-and-c.html

Its not all bad news as the following shows:

A 2024 Discussion Whether To Convert The Linux Kernel From C To Modern C++

https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss

This panel, the second at CppCon, is back by popular demand where previously we had a Tuesday night session attended by 70% of attendees, continues a series of panel at every future CppCon where we will have the opportunity to discuss the progress of Safe and Secure C++ in that year, to enable the improved use of C++ in the Automotive, Embedded, Space, Medical or any domain that requires safety and security.

Since 2023, there has been new edicts by the US government, new development in C++ Profiles, Contracts, and new blog posts to respond to the government requirement for memory-safe languages and we want to hear from all the interested parties. As such I aim to have the key players each of these members had significant developments. The C++ community also wants to hear from each of them their ideas and ask them direct questions as to why they think what they are developing will help to make C++ safe and secure.