Powered by AI: A Cambrian Explosion for C++ Software Development Tools

Thursday, October 5 • 09:35 - 10:05

by Emery Berger

Large language models like GPT-4 are achieving state of the art results in a wide variety of well-studied areas, eclipsing past work in well-studied areas like auto-completion. I argue that they should also presage a "Cambrian explosion" – a wave of radically new kinds of software development tools, all powered by AI, that will make all our lives easier. This talk will focus on several tools of particular interest to C++ developers. First, as any C++ developer knows, C++ compiler errors are notoriously verbose and can be hard to decode even for experts. To address this challenge, we created CWhy, a compiler wrapper that translates C or C++ compiler errors into readable explanations, and even proposes potential fixes. Beyond compile-time errors, C++ developers must also spend considerable time in debuggers (like `gdb` or `lldb`) trying to track down the root cause of runtime errors. To simplify this task, we created ChatDBG, a system that augments debuggers with a new command you can run for post-mortem debugging: `why`. This command performs a root cause analysis of the issue leading to the error (e.g., a segfault) and proposes a fix. For both of these projects, we share some details about their internal workings, describe how they can effectively leverage large language models, and present examples of them in action.

C++20 Modules: The Packaging and Binary Redistribution Story

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

by Luis Caro Campos

C++ modules are one of the most talked-about features introduced in C++20, but are still not widely in use. One of the biggest promises of C++ modules is to reduce overall compilation times by removing the need to have the compiler parsing the same include files across a big number of translation units. However, despite available compiler implementations, modules are still not generally in use. Why is this?

When put into practice, C++ modules introduce a dependency in the order in which translation units are built: in order to build a source file that contains a module import statement, the source file that exports the name module needs to have been compiled into a binary module interface beforehand. This calls for compilers and build systems to work together to correctly derive the order in which source files need to be compiled.

To overcome this, paper P1689 has been proposed for compilers to report the dependencies between source files, so that build tools (e.g. CMake and Ninja) can use this information to derive the correct build order. However, the currently available implementations have limitations and where all the source files that export module definitions should be visible by the same build.

How does this work in scenarios where we have dependencies (e.g. third-party) that are provided externally to the current build system? We have become accustomed to a model where a “binary” package contains, at the very least, header files (.h/.hpp) for the compiler, and libraries (.a/.so/.lib/.dylib) for the linker. How do modules fit into this model when it comes to installing and distributing prebuilt binaries? Now more files are required on the consuming side: the compiled binary module interface, and the corresponding module interface source file.

This talk will review the current state of modules in C++, by presenting the experience currently provided by the most recent versions of the relevant tools. Special focus will be put on the potential of using C++20 modules for external library dependencies, and how far we are from being able to consume external libraries using modules.

Building Effective Embedded Systems: Architectural Best Practices

Friday, October 6 • 13:30 - 14:30

by Gili Kamma

Embedded development is a complex process that brings together software, electronics, physics, mechanics, and algorithms.
Designing a system with embedded components requires careful consideration of multiple factors. However, there is a lack of knowledge regarding correct practices in building embedded systems. In my talk, I will offer valuable insights to enhance the effectiveness of embedded development, focusing on improving robustness, speed, and maintainability.

By addressing the challenges in this field, attendees will gain a deeper understanding of how to design and build embedded systems correctly. Through practical advice and best practices, I aim to empower developers to overcome obstacles and achieve successful outcomes in their projects.

Finding Your Codebases C++ Roots

Friday, October 6 • 10:30 - 11:30

by Katherine Rocha

Codebases contain all the history for a project, from designed-new features to hacked-together quick fixes that no one has come back to. Whenever new software development occurs, designed or not, the meaning of a section of code is morphed, hopefully to the intended purpose. When the next person comes along, they will need to understand the past “whys” behind decisions to create the most maintainable and cohesive codebase. This involves understanding not just the codebase’s history, but also C++’s history to effectively understand the story of how the code got to where it is now. In this talk, we will investigate the life cycle of a C++ codebase utilizing the skills and perspective of genealogy. We will address the difficulties in understanding a codebase’s C++ past, how that links to C++’s past, and how we can use that information to improve our codebases—now and in the future.

Surveying the Community: What Could Possibly Go Wrong?

Friday, October 6 • 10:30 - 11:30

by Anastasia Kazakova

There are 3 major researches in C++ community nowadays. Developer Ecosystem research by JetBrains is conducted yearly, with the infographics and the raw data published for free for everyone. Since launch we learnt many insights on how to collect and process the data to get the results which are not presenting our thoughts on state of the art but close to the real world. The knowledge starts from the way to ask questions and goes to the way we interpret the answers, including the “facepalm” issues we meet yearly.

In this talk, I'll feature the results of the recent C++ community surveys, make some comparisons, and will try to showcase how to treat the differences. We'll also dive into the survey methodology aspects, learning how to remove brand, targeting and sampling biases, as well as see how a "properly" asked question changes the data in our C++ reality. This knowledge is crucial for everyone who rely on such researches and want to use them in a correct way. Come and learn how the magic numbers are collected and how to apply them to your decisions!

The Absurdity of Error Handling: Finding a Purpose for Errors in Safety-Critical SYCL

Thursday, October 5 • 09:35 - 10:05

by Erik Tomusk

C++ is hard. Error handling is hard. Safety-critical software is very hard. Combine the three, and you get just one of the exciting problems faced by the SYCL SC working group.

SYCL is one of the most widely supported abstraction layers for programming GPUs and other hardware accelerators using ISO C++. As of March 2023, the Khronos Group has a working group tasked with specifying SYCL SC --- a variant of SYCL that is compatible with safety-critical systems. One of the key features of a safety-critical system is that its behavior must be well understood not just in normal operation, but also in the presence of faults. This raises some difficult technical questions, such as, "How do I implement deterministic error handling?" but also some more philosophical ones, like, “What does an error actually mean, and is the error even theoretically actionable?”

Much of the information on C++ error handling in safety-critical contexts focuses on RTTI and the pitfalls of stack unwinding. Although these are important considerations, I will argue that a far greater problem is a lack of agreement on what *safety* even means. This talk will focus on how *safety* in a safety-critical context differs from *safety* from a programming language design perspective. While the talk is inspired by the pain-points of C++ error handling in safety-critical contexts, the conclusions are relevant to C++ software in general. The talk will challenge the audience to rethink the situations that can be considered erroneous and to carefully consider the expected behavior of their software in the presence of errors.

I am a member of the SYCL SC working group, but this talk will contain my own opinions.

Back to Basics: Testing

Thursday, October 5 • 09:00 - 10:00

by Phil Nash

If we’re writing tests for our code we probably think we should write more - or write better tests. If we’re not already writing tests perhaps we think we should start. Or perhaps we are not, yet, convinced they are worth it?

This session will introduce you to the benefits of testing and how to get started and be effective.

We’ll look at:

* What does testing even mean?
* What types of testing are there, and what should I focus on?
* Should I use a test framework? If so which one?
* What are the testing best practices?
* What are some common challenges and pitfalls to overcome?

Noexcept? Enabling Testing of Contract Checks

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

by Pablo Halpern and Timur Doumler

Should `noexcept` be part of your function's contract? A function's *contract* is the set of pre-conditions promised by the the caller and the set of post-conditions promised by the function itself, including whether or not it throws an exception. Naively, then, it would seem that `noexcept` is a good way to indicate that your function does not throw when called in contract, but things are not so simple. In this talk, we'll review the original purpose of the `noexcept` specifier and the `noexcept` operator. We'll look at how runtime contract checks can be tested and how `noexcept` interferes with such testing. Along the way, we'll touch on the proposed contract-checking feature in C++26, eventually arriving at an alternative exception-specification annotation that would mesh far better with contract checking than `noexcept` currently does. 

Building Consensus on a Set of Rules for Our Massive C++ Codebase

Friday, October 6 • 09:35 - 10:05

by Sherry Sontag

In this talk, we will trace our efforts to build consensus across our Engineering department on how we use C++ at Bloomberg. We will use the example of how we are introducing broader naming conventions across the company’s massive C++ codebase, impacting our package management infrastructure and build tools. We will describe the lessons we’ve learned and the pitfalls we fell into as we were trying to achieve that goal, so that attendees can apply these lessons within their own organizations when introducing their own set of C++ rules.

This will also highlight the value of journalism skills in approaching engineering questions. Most important are the willingness to seek out all sides of a question; being humble enough to truly listen to even your loudest critics; and the endurance to keep asking questions until the issues become completely clear.

Our effort involved input from more than 150 people across many different application and infrastructure teams, many with different needs and coding styles. We then developed a set of rules that worked, though we also realize that the right answer will likely require ongoing flexibility.

Undefined Behavior: What Every Programmer Should Know and Fear

Thursday, October 5 • 09:00 - 09:30

by Fedor Pikus

This talk is about You-Know-What, the thing in our programs we don’t mention by name.

What is this undefined behavior every C++ programmer has grown to fear? Just as importantly, what it isn’t? If it’s so scary, why is it allowed to exist in the language?

The aim of this talk is to approach undefined behavior rationally: without fear but with due caution. We will learn why the standard allows undefined behavior in the first place, what actually happens when a program does something the standard calls “undefined,” and why it must be taken seriously even when the program “works as-is.” As this is a practical talk, we will have live demos of programs with undefined behavior and sometimes unexpected outcomes (if you are very lucky, you might see demons fly out of the speaker’s nose). Also, as this is a practical talk, we will learn how to detect undefined behavior in one’s programs, and how to take advantage of the undefined behavior to gain better performance.