CppNorth 2024

C++ is not an easy language. While its intention, especially with the new Standards since C++11, is to shift more work from the developer to the compiler, this is sometimes perceived as opaque. Knowing what a statement does is vital not only in embedded software development. It is also essential while teaching C++ when questions come up like "when and where are operators involved" or "in which places do we get an implicit type conversion".

Some tools, like Matt Godbolt's Compiler Explorer or Clang's AST dump, can show us the resulting output. However, the resulting output is not C++. This makes it hard for a C++ developer to understand. As a C++ programmer, my first language is, after all, C++. The Clang-based tool C++ Insights (https://cppinsights.io) addresses this. It aims to show the source code with the eyes of a compiler through a source-to-source transformation where the resulting output is still C++. All the intentionally hidden things become visible.

In this talk, I will present how C++ Insights has evolved in the last few years. You will learn how C++ Insights can assist you with teaching or programming. Some awesome new educational transformations can help you understand constructs like C++20's coroutines or visualize object lifetime.

By default, we think sequentially. Parallelism and asynchrony are often seen as challenging and complex. Tools to be used sparingly and cautiously, and only by experts.

But we must shatter these assumptions, for today, we live in a parallel world. Almost every hardware platform is parallel, from the smallest embedded devices to the largest supercomputers.

We must change our mindset. Anyone who writes code has to think in parallel. Parallelism must become our default.

In this example-driven talk, we will journey into the world of parallelism. We'll look at four algorithms and data structures in depth, comparing and contrasting different implementation strategies and exploring how they will perform both sequentially and in parallel.

During this voyage, we'll uncover and discuss some foundational principles of parallelism, such as latency hiding, localizing communication, and efficiency vs performance tradeoffs. By the time we're done, you'll be thinking in parallel.

C++ reflection has been a long-sought goal of users and language designers. But previous attempts have failed to get wide enough support to make it into the C++ standard or be widely implemented. A newly revised design has incorporated the lessons learned from previous proposals and is gaining momentum in the C++ standards committee.

This presentation will cover the current reflection proposal. I will go over how it works, how to use it, and how it compares to other reflection proposals and implementations. There will be plenty of code examples, compiled by real compilers that have already implemented the proposal, showing how reflection enables useful techniques that had been previously out of reach.

Attendees will come away from this session with an appreciation for the power and usefulness of reflection, and with the knowledge of how to start writing reflection-based code.

Throughout our careers, we will have the opportunity to work on many different teams and many different projects. We may sometimes work on a team that’s enjoyable, but isn't delivering too much. Other times, we might work on a team that delivers, but is no fun. If we’re really unlucky, we can end up on a team that doesn’t deliver and isn’t enjoyable. But occasionally, we can have the privilege of being part of a team that not only delivers, but is also a great team to be on.

The key question is: what makes these teams different? Why do some work and others not? Why is a team full of superstars not as good as a superstar team?

This talk will explore the different characteristics of software development teams, and will look at the different roles and responsibilities within a team. Taking an evidence-based approach, we’ll consider what makes a good team, explore how to encourage more cooperative teamwork in order to achieve better results for everyone on the team, as well as offer some ideas for how to gently improve the teams on which we are currently working.

Profile-Guided Optimization (PGO) is a compiler optimization technique that helps with optimizing software based on a collected in runtime profile. This optimization is available in all major C++ compilers like GCC, Clang, MSVC. But how smooth will be your experience when you try to adopt PGO in practice?

I applied PGO to many kinds of software (compilers, databases, log solutions, CLI tools, and many more), collected a lot of carefully hidden traps on my journey and found multiple ways of how to avoid them. In this talk I want to share with you my experience. We will discuss the following topics:
* What is PGO and why do we need it.
* PGO performance benefits in practice (with a lot of numbers for actual open-source software)
* What kinds of PGO do we have in different compilers?
* Pros and cons of each PGO way.
* Most and less common PGO traps that you can meet in your journey and how to mitigate them.
* PGO state in the C++ ecosystem: compilers, build systems, package managers support.
* A lot of pieces of advice about PGO integration into your software.
* And of course answer all your questions about PGO!

After the talk you will be much more prepared for doing PGO in practice and even will be aware about more advanced optimization techniques like Post-Link Optimization (PLO), ML-based compiler optimization and other interesting stuff from the optimization field.

C++ has some amazing and powerful language features, but they can be difficult to understand. Moving past a basic understanding of a feature and common patterns of use requires a deep understanding of the underlying language design so that you can model how it works and how to effectively use it. But how do you develop a rich and compelling model for these parts of C++?

The Carbon language aims for seamless and comprehensive interop with C++, including these complex and powerful aspects of the language. As a consequence, in order to design Carbon's features, we have to build exactly that rich and compelling model for C++ features they interoperate with. A surprising but delightful outcome is that the Carbon designs can often be used to build an even deeper and more effective understanding of C++ itself.

This talk will work through the design of two Carbon features with significant C++ overlap: variadics and overloaded methods. We will build up a design model for them, and show how you can use that model to think more deeply and holistically about the design of C++ code. It will also show how to build more expressive or robust C++ APIs through that model, even where C++ doesn't give you perfect building blocks. And most of all, it will showcase a fun and interesting way to learn about language design, and reason more deeply about the underlying principles of your code.

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 performant. The ranges library, especially with some recent C++23 additions also better exposes us to the notion of 'range-of-ranges' and multi-dimensional 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, curating and solidifying the algorithms in the STL circa 1998 (Stepanov: [STL and its Design Principles](https://youtu.be/1-CmNNp5eag)). 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 an introduction to the ranges library as an example of a breakthrough library, and discuss various aspects of composability which makes the library shine.

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

Address Sanitizer (ASAN) and Leak Sanitizer (LSAN) have a lot of options and additional functions which sometimes could be used not only for detecting memory errors and leaks.

This talk will cover LSAN internals (combined memory manager, interceptors, garbage collector which does not collects garbage, why LSAN does not work with gdb), ASAN and LSAN public interface, how to profile memory usage via ASAN or LSAN, obtaining about objects metadata, memory manager statistics and useful functions which could be used from gdb.

Also we'll try to improve LSAN diagnostic output via using non public LSAN API.

When talking about ranges I always get the same questions "but how about compile time? how about runtime?" because usually abstractions give us the impression that they might slow down either compile time or run time or both. The advantages of ranges lie in the ease of use, composability, and readability but many people cannot sacrifice run time performance for it. So that sparked the idea of using different tools to do a deep dive into the ranges code and answer these questions as objectively as possible. In this talk I will talk about the tools I used on both Windows and Linux and the insights they give into ranges code compared to non-ranges code. I will concentrate on runtime performance and memory usage. The analysis features one example written in: C-style C++, C++17 and C++23/ranges. The comparison of these styles will give you an impression which effects modernization of your code has on performance.

Let's talk about everyone's favourite topic; refactoring.

The talk will take the audience through abstract concepts related to a multi-disciplinary outlook on refactoring inspired by the late Charlie Munger. With those concepts in mind, we then look at examples where we stretch our thinking beyond a raw loop and search for solutions provided by STL algorithms and ranges. This talk is aimed at everyone from beginner to advanced and for all languages.