Shared Libraries and Where to Find Them

Tuesday, September 17 • 14:00 - 15:00 MDT

by Luis Caro Campos

Most C++ developers are familiar with the type of errors that arise when a shared library is not found. If they are really unlucky, they are have also faced a situation where the the wrong version of a library is loaded. However, a lot of us resort to suboptimal solutions just to get going, without fully addressing the root causes.

A lot of the time, we focus on the “build” process, that is, producing our binaries and executables. But getting the runtime linker/loader to locate the right libraries (and the right versions!) has a unique set of challenges that  should not be overlooked - after all, running the executables is critical for running tests, continuous integration, and obviously end-users running our apps and services.

Managing dependencies continues to be one of the top frustrations of C++ developers as per the most recents ISO C++ Developer Surveys. When it comes to shared libraries - different applications try to locate them at different times: the build system (e.g. CMake or Autotools) when configuring the build, the linker at build time, and the dynamic linker/loader at runtime.

This talk will cover in detail the different scenarios in which shared libraries need to be located, and how this is handled by package managers, build systems, and the the OS level. Emphasis will be placed on familiarizing the developer with the relevant tooling across multiple platforms, as well as associated concepts (e.g. RPATHs).

An often overlooked aspect will also be covered: how to create a self-contained, relocatable bundle for our user-facing applications, decoupled from the developer environment, as opposed to “works on my machine”.

Bridging the Gap: Writing Portable Programs for CPU and GPU

Monday, September 16 • 15:15 - 16:15 MDT

by Thomas Mejstrik

This talk presents a series of effective patterns to address challenges arising when
code is developed that shall operate seamlessly on both GPU (Cuda) and CPU environments.
This scenario is a common oversight among Cuda developers, given the substantial architectural differences between CPUs and GPUs.

The patterns presented cover a range of scenarios, from handling stray function calls, strategies for conditional compilation, exploiting constexpr functions, leveraging undefined behaviour, usage of Cuda specific macros,
conditional instantiation of templates, and managing compiler warnings and errors.

Key patterns include: "Host device everything", "Conditional function body", "Constexpr everything", "Disable the warnings", "Defensive Programming", "Conditional Host Device Template", and "Function dispatching".

We evaluate each pattern based on ease of use, maintenance overhead, applicability and known usages. Additionally, pitfalls to avoid and considerations for implementations are provided to guide developers in adopting these patterns effectively.

Reflection Based Libraries to Look Forward To

Tuesday, September 17 • 09:00 - 10:00 MDT

by Saksham Sharma

The primary reason for your code to get bored is fatigue from repetitive instructions. You write down enums, but then you also have to write their stringified version, and you also have to write a function to map the strings to the enums. You write down a class, but you have to expose every method / member in the class separately to be able to bind your class to a Python program (for example).
Reflection is (potentially / hopefully) showing up for C++26, having already been forwarded from the SG7 subgroup on reflection / compile time programming to the LEWG and EWG. This talk will discuss everything there is so far on reflection, and we will lead up to three library ideas based on reflection:

Python bindings
ABI hashing (hashing a type for efficient compatibility checking)
A better std::any variant type with duck typing ��
Come attend this talk if you'd like to hear about cool new library possibilities that have opened up with reflection!

For background, we will look at a little bit of context and how reflection works in some other languages, and will explore how the P2996R1 paper’s proposed version of reflection looks in practice, with some real use-case inspired code.

Taming the C++ Filter View

Tuesday, September 17 • 16:45 - 17:45 MDT

by Nicolai Josuttis

C++20 introduced "views" as easy-to-use building blocks for processing the elements and values of containers and ranges.
The filter view is one of the key views, because filtering collections of data to process only elements that satisfy a specific constraint or requirement is one of the most important use cases of dealing with ranges and views.

Unfortunately, the filter view is also one of the most surprising C++ standard views. Even for simple use cases, you can easily get:
- Unexpected functional behavior
- Surprising compile-time errors with cryptic error messages
- Fatal runtime errors (without even noticing them)

There are reasons for the design of the filter view. For a successful filtering of elements you should know and understand the design and all of its consequences.

The talk will demonstrate all the issues with simple real-work examples and explain both the motivation and consequences if this design in practice. Listen and learn aspects you would not expect but have to know when using the filter views and views in general.

Implementing Ranges and Views

Wednesday, September 18 • 16:45 - 17:45 MDT

by Roi Barkan

Since `ranges` were introduced to C++20, a new paradigm was presented to us C++ developers. This paradigm, [sequence oriented programming](https://cppcast.com/sequence_oriented_programming/) allows easy expression of useful algorithms, helps us decompose problems into smaller-clearer sub-problems and has the potential of increasing the readability and maintainability of solutions we develop to difficult problems.

Though rich and diverse, the set of tools in our `ranges` toolbox is at its infancy, and the robust design of the library makes it possible for us to extend it with algorithms and views on our own. Doing so can increase our productivity, enrich our vocabulary and also be fun and challenging.

In this talk I'll discuss the structure of the ranges library in terms of its main `concept`s and how it was designed to be extensible (especially as on C++23).

We will focus on the implementation `range views`, and go over several examples of how new views which aren't part of the standard should be designed and implemented, in a way that fits with the rest of the `ranges` library.

Join me in the development of range adapters as we learn about range categories, concepts, adapters, customization-point-objects and range-adapter-closures.

C++/Rust Interop: Using Bridges in Practice

Friday, September 20 • 10:30 - 11:30 MDT

by Tyler Weaver

A practical guide to bridging the gap between C++ and Rust. We cover bindings, including a manual approach, and compare them with generated bindings using CXX.  We also show how to link CMake with Cargo and link with transitive C++ dependencies using Conan.

Irksome C++

Thursday, September 19 • 16:45 - 17:45 MDT

Walter E Brown

As much as I like C++, it is certainly not free of -- let's say -- quirks.  Both the core language and the standard library exhibit idiosyncracies, sometimes even in conflict with one another.

Some of these "oops" may be historical in origin.  However, most are due to the spectrum of viewpoints held by the hundreds of contributors who have participated in C++ standardization to date.

This talk points out many of these inconsistencies and numerous other infelicities in naming, behavior, or both.  Come see whether *your* pet C++ peeve is mentioned!

Building Cppcheck - What We Learned from 17 Years of Development

Wednesday, September 18 • 09:00 - 10:00 MDT

by Daniel Marjamäki

Cppcheck has been evolving for 17 years, guided by a clear philosophy: minimal false positives and ease of use. This presentation will share the insights we've gained during its development. Our approach to easy configuration is a double-edged sword, providing user-friendly setup while occasionally leading to lower recall. We maintain a strict definition of false positives, ensuring the tool does not warn about well-written, functional code. This principle, while challenging, drives us to fix rather than suppress false positives. A core philosophy of Cppcheck is to learn from mistakes. When an issue is identified, we strive to implement checkers to prevent similar mistakes in the future.

The open-source community plays a crucial role in Cppcheck's evolution. We collaborate to enhance the tool, scanning large codebases like Debian's source code to identify inconsistent or dangerous code and measure false positives. We also explore how abstractions, compiler annotations, and contracts can improve SCA tools' precision and performance. This talk will provide a comprehensive look at the lessons learned and the continuous improvement of Cppcheck.

Data Is All You Need for Fusion

Monday, September 16 • 16:45 - 17:45 MDT

by Manya Bansal

Functions are the fundamental unit of interoperability in software design: users write applications by composing functions provided by various libraries. However, naive function composition can result in poor performance due to memory overheads that exist at function boundaries. Operator fusion --- combining the execution of several operators into one operator --- is a well-known technique to combat this overhead. Previous solutions to add fusion rely on complex, monolithic compilers and languages that force performance engineers to rediscover old solutions in new ecosystems, leading to decades of performance engineering work going underutilized. In this work, I attempt to identify the minimal ingredients required to enable fusion on top of existing library interfaces. In doing so, I propose a lightweight enrichment of function interfaces that exposes data production and consumption patterns of functions. I show how to implement these ideas in C++ and demonstrate the benefits of my system by showing that it is competitive with state-of-the-art high-performance libraries, and that it can fuse across library boundaries for unforeseen workloads.
 

Multi Producer, Multi Consumer, Lock Free Atomic Queue

Tuesday, September 17 • 0900 - 10:00 MDT

by Erez Strauss

This presentation introduces a multi-producer, multi-consumer, lock-free queue with unique characteristics. We will cover the C++17 implementation and the std::atomic features required for this queue based on the CPU atomic instructions and discuss the queue's portability across various CPU architectures, beyond just X86_64 and runtime environments.

Efficient message queue-based communication between threads is crucial for optimal performance in multi-threaded applications. Queues are fundamental data structures that interact with various aspects of the application environment, including schedulers, memory allocation systems, and CPU hardware architectures.

Many use cases such as trading platforms, games, audio processing and other fields have strict latency and scaling requirements and this queue implementation has proved to reduce system latencies.

The presentation will feature the design of the queue, the required template language features, bandwidth and latency consideration, and multiple demo applications. Comparing this queue implementation’s benchmark results with other existing queues will follow. Finally, we will discuss potential future work and areas for improvement.

Join us to explore how this innovative queue implementation can improve your multi-threaded application performance.

All presentation materials, including the C++17 source code, slides, benchmarks, and demo applications are available on GitHub.