Exploration of Strongly-typed Units: A Case Study from Digital Audio

Wednesday, October 4 • 14:00 - 15:00

by Roth Michaels

API or math mistakes with units can cause problems ranging from a digital audio processing outputting silence to crashing your Mars rover—we’ll discuss real-life examples of both!

The combination of user-defined types, conversion operators/constructors, and operator overloading in C++ give us the tools to use strong-types and avoid unit mistakes; std::chrono is a great example of this that everyone should be using. Unfortunately, when dealing with units beyond time many developers still use primitive types encoding units in variable names or comments because the standard does not offer any tools for user-defined units.

In this talk we will look at the mp-units library which has been proposed for standardization in P1935 (A C++ Approach to Physical Units). We will look at the implementation of various units used in digital audio / DSP that go beyond “physical” units and what the experience is like to develop your own units with this library/proposal.

Applicative: The Forgotten Functional Pattern

Wednesday, October 4 • 14:00 - 15:00

by Ben Deane

Monads get all the press. Functors are often presented as a prerequisite to monads. Applicative (functor) almost never gets mentioned. But it's massively useful - to the point where a lot of the time when we think about a "monadic interface" what we really want is an applicative interface.

This talk will put applicative in the limelight, showing how it works and why it's so powerful, with lots of examples grounded in code; there are no category theory diagrams in this talk. Attendees will come away with a solid understanding of the applicative pattern and its many uses. And as a byproduct, their opinions of monads will probably change too.

Optionals. Expected. Ranges. Futures. Parsing. Validation. Error Handling. Transforms. Functions themselves. These are all examples where thinking in terms of applicatives (and importantly, NOT just reaching for "a monadic interface") helps us write simpler, more composable code.

If you're kind of fuzzy about functors and monads, what's missing is probably the third piece of the puzzle: applicative.

A Journey Into Non-Virtual Polymorphism

Wednesday, October 4 • 09:00 - 10:00

by Rudyard Merriam

Join me on an introductory journey into polymorphism that doesn't use class inheritance and virtual functions. I'll share my amazement at how polymorphism permeates C++. Then we'll visit the long-used Curiously Recurring Template Pattern (CRTP) with its modernization using implicit this.

Do you like lambdas? So does the override pattern, which uses them to handle std::tuples and std::variants with std::apply and std::visit.

Want to walk through a container of disparate types invoking their functions? You'll see this and all the above in code examples galore.

Afterward, you'll be eager to learn more on your own!

Object Lifetime: From Start to Finish

Wednesday, October 4 • 14:00 - 15:00

by Thamara Andrade

beginner, object lifetime, temporary objects

Six Ways for Implementing Math Expressions Calculator

Wednesday, October 4 • 09:00 - 10:00

by Amir Kirsh

The tradeoffs involved in using runtime polymorphism, based on virtual functions, versus static polymorphism, which relies on Templates, are widely discussed. In this presentation, we aim to delve into this subject by demonstrating a straightforward example of creating a Math Expression Calculator. We will begin with examining the basic pointer-based polymorphism, moving to using smart pointers, comparing the usage of unique_ptr vs. shared_ptr, then explore templates and variadic templates while going through additional topics such as templates specialization, constexpr, type traits, C++20 concepts and more.

The talk presents the multi-paradigm power of C++ and is relevant for any C++ developer who is considering different implementation approaches for modeling the different behavior of entities.

Lock-free Atomic Shared Pointers Without a Split Reference Count? It Can Be Done!

Tuesday, October 3 • 14:00 - 15:00

by Daniel Anderson

Smart pointers such as std::unique_ptr and std::shared_pointer are the recommended way to manage dynamic memory in C++ programs. At least, that is what we try to teach people. But what if you are writing parallel and concurrent code, can we will make use of std::shared_ptr? Yes, but only if concurrent modifications are done via a std::atomic＜std::shared_prt＞! Atomic smart pointers were recently introduced to the C++20 standard for this purpose, however, existing implementations in major standard libraries are not lock-free. This makes them impractical for applications with heavy concurrency, as their performance degrades badly.

There are several well known implementations of a lock-free atomic shared pointer, such as Folly's, and Anthony William's which is included in a commercial library. These implementations and several others are all based on the so-called "split reference count" technique, which solves the problem of atomically modifying the reference count and the object pointer when performing an update operation. This technique is difficult to make fully portable however, since it either relies on a double-word compare-exchange operation, or packs a reference count inside the "unused" high-order bits of the pointer.

In this talk, we describe a strategy for implementing lock-free atomic shared pointers without a split reference count. The solution is surprisingly simple and elegant, as it does not require adding any fields to the shared pointer or atomic shared pointer and does not hide anything inside the bits of the pointer. Under the hood, it makes use of hazard pointers and deferred reclamation. Since hazard pointers are on track for inclusion in C++26, this implementation is timely, simple to implement with nearly-standard C++, and achieves excellent performance.

Why Loops End

Tuesday, October 3 • 15:15 - 16:15

by Lisa Lippincott

When we write a loop in a program, we usually intend that each execution of the loop will eventually end. To meet that intention, we should understand the reasons why loops end, and, to give others confidence in our code, we should learn to communicate those reasons.

In this talk, I will examine the reasons why loops end, and present a scheme for expressing those reasons formally within the source code of a program, in a lightly extended version of C++. Starting from procedural first principles of stability of objects, substitutability of values, and repeatability of operations, I will show how reasons for loops to end can be expressed directly by the program’s flow of execution within the neighborhood of the loop.

Back to Basics: Initialization

Wednesday, October 4 • 09:00 - 10:00

by Ben Saks

C++ has many ways to initialize objects, and even experienced C++ programmers often have difficulty remembering exactly what each one means. For example, which constructor of T does each of the following statements invoke?

T t1(1, 2, 3);
T t2{4, 5, 6};
T t3 = t2;

Moreover, the context of the initialization can affect how the compiler interprets certain constructs. As such, we often have difficulty deciding which form of initialization to use. Choosing a form of initialization is especially difficult when we don’t know the exact type of the object that we’re initializing (i.e., when the type of the object is a template type parameter).

In this session, we’ll explore the similarities and differences among each form of C++ initialization and how the initialization rules have changed over time. Focusing on the common elements, we’ll see how C++’s initialization rules are (while not simple) not quite as complex as they might first appear. We’ll see how the Standard Library chooses which form of initialization to use and how that affects similar code that you might write yourself. We’ll also discuss how you can design your classes to make them easy to use in light of the initialization rules.

You’ll leave this session with a clearer understanding of exactly what each form of initialization means. With this knowledge, you’ll be better able to decide when each form of initialization suits your needs, which will help you write code that’s more expressive, robust, and maintainable.

A Common Package Specification: Getting Build Tools to Talk to Each Other: Lessons Learned From Making Thousands of Binaries Consumable by Any Build System

Tuesday, October 3 • 16:45 - 17:45

by Diego Rodriguez-Losada

There is a lot of previous work and proposals for a “Common Package Specification”, but there has been little implementation experience with real-world production usage at scale with feedback from diverse groups, something critical for such a specification to be technically viable. Some mechanisms like CMake exported targets/config files are becoming more popular with the continuous adoption of CMake, and pkg-config (.pc) files are also a popular mechanism in GNU systems, but those are still tool-specific and it is still not possible nowadays to consume pre-built binaries in a generic way by every build system.

Since the Conan C++ package manager was released 7 years ago, one of its main design goals was to be tool agnostic and let any package created with any build system to be usable by any other build system. This talk will describe the abstraction that has been and is widely used by +1500 open source Conan packages covering the vast majority of popular C and C++ open source libraries, and thousands of teams using it in production for their own private packages. Based on this experience and the lessons learned, the talk will describe how a “Common Package Specification” should look like:

- Representation of the different folders necessary to define a package: include directories, library directories, binary directories, build files directories, etc.
- How paths should be relative so binary redistribution and re-usage in other machines is possible.
- Representation of the different preprocessor definitions, compiler flags, sysroot.
- Representation of “components”, when a package contains more than one library that can be optionally created, optionally consumed, and includes relationships between components.
- Representation of custom build-system “properties”, that allows to customize some behaviors for specific build systems.
- Achieving scalability by decoupling the binary requirements from the consuming specification (this talk focus only on the second one)

While this basic “Common Package Specification” can be easily represented and serialized in a file, like json or yaml that travels together with the package, there are some implementations challenges that will be discussed:

- How such a generic package specification maps to the existing popular build systems, including CMake, MSBuild, Autotools, Meson, etc, and how this mapping can be leveraged for faster adoption.
- In some cases, the same binary can provide different information to consumers like different preprocessor directives, based on some user configuration. How could this problem be solved with the typical declarative syntax of formats like json or yaml?
- How the packages and the “Common Package Specification” files are found and used by the build system?
- Is it possible to “consume” a package while it is still under development, so it doesn’t have the artifacts to consume in typical “include”, “lib” folders, but in a developer “source” layout?
- What happens at runtime? Beyond the common PATH, LD_LIBRARY_PATH, etc, some packages need to have defined some environment variables to correctly work. Can this information be included in the “Common Package Specification” too?
- Common operations over specification files, like aggregation of components or merging (in the right order, following the topological order of the graph), necessary for build-systems like autotools or NMake.

This talk will summarize years of real world experience contributing towards the goal of having a “Common Package Specification” for C and C++, that will allow full interoperability between build systems and package managers, one of the most desired and demanded functionalities in the C++ tooling ecosystem.

Taro: Task-graph-based Asynchronous Programming Using C++ Coroutines

Tuesday, October 3 • 16:45 - 17:45

by Dian-Lun Lin

Task graph computing system (TGCS) plays an essential role in high-performance computing. Unlike loop-based models, TGCSs encapsulate function calls and their dependencies in a top-down task graph to implement irregular parallel decomposition strategies that scale to large numbers of processors, including manycore central processing units (CPUs) and graphics processing units (GPUs). As a result, recent years have seen a great deal amount of TGCS research, just name a few: Taskflow, oneTBB, Kokkos-DAG, and HPX. However, one common challenge faced by TGCSs is the issue of synchronization within each task. For instance, in scenarios where a task involves executing GPU operations, a CPU thread typically needs to wait until the GPU completes the operations before proceeding further. This synchronization overhead can hinder performance and limit the overall scalability of TGCSs.

The introduction of C++ coroutines in C++20 has revolutionized asynchronous programming, offering improved concurrency and expressiveness. However, integrating TGCS with C++ coroutines presents several challenges. Firstly, existing TGCS solutions are not compatible with C++ coroutines, as the coroutine paradigm deviates from traditional C++ programming. This incompatibility makes it difficult to seamlessly incorporate coroutines into existing TGCS frameworks. Secondly, C++ coroutine programming is extremely difficult and requires a solid understanding of the underlying concepts and mechanisms. The introduction of a new paradigm adds complexity and a steep learning curve for developers. Lastly, while C++ coroutines offer a powerful mechanism for managing asynchronous operations, designing and implementing an efficient scheduler to leverage their capabilities remains challenging. To fully exploit the benefits of C++ coroutines, there is a need for a specialized scheduler that can handle large numbers of coroutines and make optimal use of hardware resources.

To address these challenges, we present Taro: Task-Graph-Based Asynchronous Programming using C++ Coroutine. Taro offers a task-graph-based programming model for C++ coroutines, simplifying the expression of complex control flows and reducing development complexity. Additionally, Taro incorporates an efficient work-stealing scheduling algorithm tailored for C++ coroutines, minimizing unnecessary context switches, CPU migrations, and cache misses.

In this session, I will introduce Taro's programming model and demonstrate how Taro can enable efficient multitasking between CPU and GPU tasks, avoiding blocking wait on CPU threads for GPU tasks to finish. I will show the example code for using Taro. Finally, I will demonstrate how our solution can improve the performance of a real-world RTL simulation workload and microbenchmarks. Taro will be open-source and available on GitHub.