September 2023 : Standard C++

Home » Blog » 2023 » September

« Prev Next »

September 2023

CppCon 2023 A Journey Into Non-Virtual Polymorphism -- Rudyard Merriam

By Blog Staff | Sep 18, 2023 06:15 PM | Tags: None

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 Journey Into Non-Virtual Polymorphism

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

by Rudyard Merriam

Summary of the talk:

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!

CppCon 2023 Object Lifetime: From Start to Finish -- Thamara Andrade

By Blog Staff | Sep 18, 2023 11:05 AM | Tags: None

Object Lifetime: From Start to Finish

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

by Thamara Andrade

Summary of the talk:

beginner, object lifetime, temporary objects

CppCon 2023 Six Ways for Implementing Math Expressions Calculator -- Amir Kirsh

By Blog Staff | Sep 18, 2023 08:02 AM | Tags: None

Six Ways for Implementing Math Expressions Calculator

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

by Amir Kirsh

Summary of the talk:

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.

Inside STL: unordered_map, unordered_set, unordered_multimap, & unordered_multiset -- Raymond Chen

By Blog Staff | Sep 18, 2023 07:29 AM | Tags: None

The C++ standard library provides hash-based associative containers unordered_map, unordered_set, unordered_multimap, and unordered_multiset.

All of these collections are hash tables with different payloads. The unordered_map and the unordered_multimap use a std::pair<Key, Value> as the payload, whereas the the unordered_set and the unordered_multiset use a Key as the payload.

Inside STL: The unordered_map, unordered_set, unordered_multimap, and unordered_multiset

By Raymond Chen

From the article:

Conceptually, the hash table consists of a bunch of buckets, and each bucket contains a linked list of the nodes that fall into that bucket. (This design is known as open hashing or separate chaining.) However, that’s not how the information is structured internally, because iterating through a traditionally-structured hash table requires more state than a single pointer: When you reach the end of each hash chain, you need some other information to tell you which chain to enumerate next.

C++ standard library implementations instead structure the hash table like this:
struct hashtable
{
    using hint = std::list<payload>::iterator;

    std::list<payload> list;
    std::vector<hint> buckets;
};
The list is a linked list of payloads, sorted by bucket. The buckets is a vector of iterators (pointers) into the list that tells you where each bucket begins. Each bucket implicitly ends when the next bucket begins, or (for the last bucket) when the end of the list is reached.

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

By Blog Staff | Sep 16, 2023 07:58 PM | Tags: None

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

By Blog Staff | Sep 15, 2023 08:04 PM | Tags: None

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

By Blog Staff | Sep 15, 2023 07:00 PM | Tags: None

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

By Blog Staff | Sep 15, 2023 02:56 PM | Tags: None

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

By Blog Staff | Sep 15, 2023 09:00 AM | Tags: None

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

By Blog Staff | Sep 14, 2023 07:48 PM | Tags: None

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.