Leveraging a Functional Approach for More Testable and Maintainable ROS 2 Code

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

by Bilal Gill

In the field of robotics, Robot Operating System (ROS) is the de facto middleware of choice across academia and industry. As most code examples in ROS utilize an object-oriented approach, challenges can arise when writing tests for production code due to the boilerplate code ROS introduces, often leading to unexpected bugs or flaky tests. This talk explores ways to mitigate those issues by using a functional approach. By adopting this approach, we can minimize the impact that ROS or other middleware has on your code, preventing it from becoming tightly coupled and brittle.

Attendees can expect an overview of ROS 2 and the conventional programming approach typically associated with it. We'll delve into how tests are usually constructed and pinpoint potential sources of bugs and flakiness. Following this, we will introduce a functional approach to writing test code. By the end of this talk, attendees will learn an alternative method of architecting their ROS 2 code and also understand how this approach can lead to more robust, maintainable, and testable code.

The Au Library: Handling Physical Units Safely, Quickly, and Broadly

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

by Chip Hogg

We present Au: a new open-source C++ units library, by Aurora.  If you've rejected other units libraries because they couldn't meet your needs, check out Au (pronounced, "ay yoo").  It combines cutting-edge developer experience (fast compilation, simple and readable compiler errors) with wide accessibility (C++14 compatibility, single-header delivery option).  You can be up and running with Au in your project --- in any build system --- in less time than it takes to read this abstract!

We'll orient the viewer by providing a decision framework for choosing a units library, and using this framework to compare several leading options. We'll also see how these libraries influence each other. For example, Au has several compelling features inspired by other libraries, such as the concise and readable compiler errors of mp-units, and the frictionless single-header delivery of the nholthaus library --- in fact, Au is the first library to provide both these features at once. Au has also provided many new features of its own, including: fully unit-safe APIs; an adaptive "overflow safety surface" that governs unit conversions; on-the-fly composition for units and prefixes; smart, unit-aware rounding and inverse functions; and more.

Finally, Au has a notably low barrier to migration --- in either direction.  We'll explain how to set up a correspondence between Au and any other units library.  Even though neither library knows about the other, you'll be able to pass Au-typed variables to APIs which take the other library's types, and vice versa.  This doesn't just make it easy to switch to Au; it promises a smooth upgrade path to any better library which comes along later (such as a future C++ standard units library).  With such a low barrier to entry, give Au a try, and find out what it feels like to get effortlessly correct handling for all your physical quantities!

Back to Basics: Iterators

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

by Nicolai Josuttis

One key success factor of C++ was the introduction of the Standard Template Library (STL) bringing together containers/ranges and algorithms using iterators as glue API to iterate over elements of collections.

This talk will present the basics of the design of iterators, the various consequences, remarkable corner cases, and what this means when using ranges and views as introduced with C++20.

"Distributed Ranges": A Model for Building Distributed Data Structures, Algorithms, and Views

Monday, October 2 • 16:45 - 17:45

by Benjamin Brock

Writing programs that run on clusters of computers is notoriously difficult. Distributed data structures can simplify this problem by automatically splitting up data across multiple memory spaces or nodes in a distributed memory program. Algorithms in most distributed data structures libraries, however, are not generic, but operate only on a specific data structure. In this work, we discuss how modern C++ features like concepts, customization points, and the ranges library can be used to support generic algorithms and views that can interoperate with multiple distributed data structures. We first discuss background in distributed computing and distributed data structures, including common techniques used to create high-level distributed data structures. We then show how customization point objects and concepts can be used to allow the implementation of generic algorithms that can be used with any distributed data structure as long as it fulfills a "distributed range" concept. We then show how to implement views that satisfy this concept, allowing algorithms to operate on lazily evaluated views of distributed data structures. Finally, we discuss two implementations of this model, for multi-GPU and multi-node programs, as well as performance considerations when running on state-of-the-art HPC systems.

Expressing Implementation Sameness and Similarity in Modern C++ 

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

by Daisy Hollman

Polymorphism is among the most widely discussed introductory topics in software engineering. Often couched in a vague context of code reuse, much of this introductory focus nonetheless revolves around interface similarity. More advanced discussions of code reuse in software engineering typically revolve around general topics like the maintainability cost of code coupling, but usually avoid discussing the merits of advanced language-specific mechanisms for code reuse. Furthermore, very little is made of the information loss and cognitive load associated with poor expression of sameness in implementation, regardless of interface coupling concerns.

In this talk, we will examine the wide spectrum of tools for expressing “sameness” in modern C++. Beyond introductory “is-a” inheritance and runtime polymorphism, we will delve into templates, concepts, mixins, CRTP, C++23’s “deducing this,” and a number of more advanced techniques on the spectrum from generic programming to template metaprogramming. We will explore the long-term software engineering costs and benefits of each of these mechanisms. In each case, we will discuss important trade-offs, such as runtime and compile-time overhead, mechanistic complexity versus “sameness” information loss, code coupling, maintainability, and the ability to adapt to evolving implementation needs over time. Finally, we will discuss mechanisms for expressing “sameness” that are difficult or impossible in modern C++—such as dependency injection and aspect-oriented programming—but that are commonplace in other languages. We will delve into both the minimal and ideal language features that would enable these paradigms to become a part of the C++ toolbox, and we will discuss the outlook for the inclusion of such features in future versions of standard C++.

C++ Exceptions and Memory Allocation Failure

By Wu Yongwei

C++ exceptions are habitually disabled in many software projects. A related issue is that these projects also encourage the use of new (nothrow) instead of the more common new, as the latter may throw an exception. This choice is kind of self-deceptive, as people don’t usually disable completely all mechanisms that potentially throw exceptions, such as standard library containers and string. In fact, every time we initialize or modify a string, vector, or map, we may be allocating memory on the heap. If we think that new will end in an exception (and therefore choose to use new (nothrow)), exceptions may also occur when using these mechanisms. In a program that has disabled exceptions, the result will inevitably be a program crash.

However, it seems that the crashes I described are unlikely to occur… When was the last time you saw a memory allocation failure? Before I tested to check this issue, the last time I saw a memory allocation failure was when there was a memory corruption in the program: there was still plenty of memory in the system, but the memory manager of the program could no longer work reliably. In this case, there was already undefined behaviour, and checking for memory allocation failure ceased to make sense. A crash of the program was inevitable, and and it was a good thing if the crash occurred earlier, whether due to an uncaught exception, a null pointer dereference, or something else.

Now the question is: If there is no undefined behaviour in the program, will memory allocation ever fail? This seems worth exploring.

Open Content: C++ Conversation: Object Lifetime

Monday, October 2 • 12:30 - 13:30

by Jason Turner

Want to learn more about C++ in a highly interactive way?

We will have a lunchtime group conversation about C++ Object Lifetime. We will discuss the types of Object Lifetime that exist in C++, and go through some fun puzzle-like exercises together.

Expect a casual, relaxed, fun, interactive setting to spend your lunch time!

Back to Basics: Debugging

Monday, October 2 • 11:00 - 12:00

by Greg Law

Everyone knows that debugging is twice as hard as writing a program in the first place. Fortunately, there is more help available than you might have thought. GDB is much more powerful than most people realize; Valgrind and Address Sanitizer can catch many common bugs before they wreak havoc; time-travel debugging can turn even the most intractable nightmarish bugs into pussycats. This fast-paced talk is light on slides and heavy on demos to show you what's available and how to use it. Familiarity with the tools available to you is an essential part of being a great programmer; you will leave this talk at least one step closer to programming zen.

Cache-friendly Design in Robot Path Planning

Monday, October 2 • 17:20 - 17:55

by Brian Cairl

Point-to-point planning is a major component in virtually all mobile robotic systems. These systems may require agents to generate paths over very large areas on demand; and sometimes several more times during their journey as part of intelligent recovery routines under dynamic environmental conditions. Since planning over large areas is a resource-intensive operation, particularly in higher-dimensional state-spaces, planning routines must be carefully tuned to execute as efficiently as possible so as to prevent perceptible delays in robot responsiveness.

Attendees can expect an overview of common planning algorithms used in robotics, such as Dijkstra's and A-star, to provide a motivating context. Rather than focus on time saving tricks specific to a particular environment or robot morphology, we will instead focus on getting the most out of these algorithms by way of leveraging cache-friendly design of requisite graph and memoization structures; and memory layouts. In particular, we will focus on achieving these results using common C++ STL facilities; and compile-time facilities to promote generic design, where possible. Finally, we will provide comparisons between naive and cache-optimized implementations; and guides for effectively profiling these algorithms for system-specific tuning purposes.

Effective Ranges: A Tutorial for Using C++2x Ranges

Monday, October 2 • 16:45 - 17:45

by Jeff Garland

This course provides in introduction to using C++ ranges effectively. Ranges are the largest revamp of the Standard Template Library (STL) in 20 years and impacts daily C++ programming dramatically. The presentation provides a survey of C++20 and C++23 ranges and their application. Note that C++14/17 programmers can also benefit since Range v3 library provides an implementation of many of the discussed facilities.

The tutorial goes beyond the basics to explore what's behind the ranges library. For example, understand the key differences between algorithms and views and when to apply them. We'll look at some of the concepts used in the design of ranges. And finally we'll explore how ranges fits into the wider standard library with i/o integration, collection integration, and support of legacy stl algorithms.

Chock full of example code this tutorial will bootstrap programmer's usage of std::ranges.