News

CppCon 2023 Lock-free Atomic Shared Pointers Without a Split Reference Count? -- Daniel Anderson

Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!

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

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

by Daniel Anderson

Summary of the talk:

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.

CppCon 2023 Why Loops End -- Lisa Lippincott

Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!

Why Loops End

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

by Lisa Lippincott

Summary of the talk:

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.

CppCon 2023 Back to Basics: Initialization -- Ben Saks

Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!

Back to Basics: Initialization

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

by Ben Saks

Summary of the talk:

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.

CppCon 2023 Getting Build Tools to Talk to Each Other: Lessons Learned -- Diego Rodriguez-Losada

Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!

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

Summary of the talk:

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.

CppCon 2023 Taro: Task-graph-based Asynchronous Programming Using C++ Coroutines -- Dian-Lun Lin

Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!

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

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

by Dian-Lun Lin

Summary of the talk:

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.

CppCon 2023 BehaviorTree.CPP: Task Planning for Robots and Virtual Agents -- Davide Faconti

Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!

BehaviorTree.CPP: Task Planning for Robots and Virtual Agents

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

by Davide Faconti

Summary of the talk:

In this presentation, we will introduce BehaviorTree.CPP, a library that is becoming increasingly popular in robotics and used to implement Task Planning.
Behavior Trees are an alternative to Hierarchical Finite State Machines; this approach was originally used in the game industry.

In the first part of this presentation, we will teach what a Behavior Tree are and their advantages, when compared with Finite State Machines; we will also focus on the exclusive features that this library has, when compared to other open source alternatives.

In the second part, we will dive into the technical details of the implementation, in particular how we use design patterns such as Factory, Observer, Safe Type Erasure, Concurrency and even a custom embedded scripting language.

Inside STL: The deque, design -- Raymond Chen

RaymondChen_5in-150x150.jpgThe C++ standard library deque is a double-ended queue that supports adding and removing items efficiently at either the front or the back.

Inside STL: The deque, design

By Raymond Chen

From the article:

All three of the major implementations of the C++ standard library use the same basic structure for a deque, but they vary in both policy and implementation details.

First, let’s design a simple version of a deque that stores its elements in an array.

template<typename T>
struct simple_deque
{
    T* elements;
    T* first;
    T* last;
    size_t capacity;
};

For example, a deque of three integers might look like this:

capacity = 8
size = last − first = 3
 

The elements points to an array whose length is given by the capacity member’s value of 8. In that array, the first three elements are not in use, but which could be used in the future. We’ll call them spares. Next come three elements holding the values 1, 2, and 3, followed by two more spares. The first element in use (1) is pointed to by first, and one past the last element in use is pointed to by last.

CppCon 2023 More Ranges Please -- Roi Barkan

Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!

More Ranges Please

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

by Roi Barkan

Summary of the talk:

Ranges are one of the major additions of C++20, in which our main abstraction for sequences shifted from iterator-pairs into full fledged concepts, allowing better composability, expressibility and safety when working with bounded and even unbounded one dimensional sequences of data. The fluent use of the pipe-operator gave us power to write complex functional-style algorithms which are both highly readable and perfomant. The ranges library, especially with some recent C++23 additions also better exposes us to the notion of 'range-of-ranges' and multi-dimentional spans, which weren't in focus of the STL in prior versions of the language.

One key feature of the STL since the last century was the large number of algorithms and building blocks which seemed woven together and gave us a vocabulary by which algorithms could be expressed with little need to work with raw loops.

Together with the introduction of ranges, the STL has also gained various range-based algorithms (as well as views and adapters), yet most of those algorithms were basic adaptations of the ones that are available in the iterator-pair model.

In a talk from 2002, the primary designer of STL described the process of gathering, currating and solidifying the algorithms in the STL circa 1998 (Stepanov: STL and its Design Principles). My talk aims to apply a similar process to the universe of C++20/C++23 ranges, and propose potential additions to our vocabulary when developing range-based algorithms.

In this talk, we will start with a relatively theoretical introduction of the values and merrits of writing software systems as libraries, and get an introduction to the ranges library as an example of a breakthrough library.
Then, we will go over a variety of algorithms which currently don't exist for ranges, describe their potential value, and discuss whether they can or should be added to the standard.

A few examples of algorithms which will be covered:

Algorithms for sorted ranges, such as take_between and histogram, ...
Algorithm for ranges-of-(sorted-)ranges, such as merge, set_union, set_intersection, ...
Algorithms which might require some helper data structures, such as histogram (for non sorted ranges)
Algorithms related to generation and processing of permutations, such as order.
As we go through the various examples, we'll discuss what might be good candidates for addition to the STL (and reference prior talks on the topic), the notion of sorted ranges, and hopefully leave the talk with a good desire to compose algorithms in the brave new world of ranges

CppCon 2023 Visual Studio: Make Debugger, Diagnostics Improvements, Video Games, & More -- Li/Girmay

Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!

What's New in Visual Studio: CMake Debugger, Diagnostics Improvements, Video Games, and More

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

by David Li and Mryam Girmay

Summary of the talk:

Another year of CppCon, another year of work on making Visual Studio a better IDE for everyone, no matter what platform you're targeting.

In this talk, we'll demonstrate the last year's work across the IDE, toolchain, vcpkg, and GitHub: leak sanitizer and advanced address sanitizer support for finding security holes, a host of tools for Unreal Engine, the new CMake Debugger, step-by-step macro expansion, and more. Catch up on improvements for highlights from previous years, such as Build Insights integration in Visual Studio and new tools for understanding complex template compilation errors

Come along to learn all about the latest in our tooling, and to get a peek into our future plans.