Embracing CTAD

Wednesday, October 4 • 15:15 - 16:15

by Nina Ranns

Class template argument deduction, or CTAD, is a C++17 feature that has divided the experts into those who consider it very helpful and those who wish it never came to be. What is it, how can it make your life easier, and what makes some wary of it ? We explore the answers to all these questions while covering the history and the current state of CTAD, so you too can form your own opinion on the subject.

Time Is of the Essence: A Case Study on Using std::future for Robot Drivers

Wednesday, October 4 • 15:15 - 16:15

by Anthony Baker

When it comes to robot control software, timing is important. In this presentation, we will examine the trade-offs of an asynchronous approach to writing control software to interface with robot hardware, using modern c++ features, versus a synchronous one. The audience will be introduced to the widely used robot control framework for ROS(Robot Operating System) 2, ros2_control, and a couple of robot drivers utilizing it, one for the Robotiq 2f 85 gripper and one for the Kinova Gen3 robot arm. The presentation will feature quantitative benchmarking data to observe the performance of the asynchronous and synchronous approaches, as well as video examples of both approaches in action on the robot hardware.

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.