Meeting C++ 2023 - the last online conference?

by Jens Weller

A few days ago it caught my attention that Meeting C++ 2023 would be the last C++ organisation with an online part of its conference.

This is the case because last year the online part did find its interest in the C++ community. I think it serves the goals of Meeting C++ to continue an online presence for the conference as long as this is feasible...

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.

C++20 Dynamic Allocations at Compile-time

By Andreas Fertig

You may already have heard and seen that C++20 brings the ability to allocate dynamic memory at compile-time. This leads to std::vector and std::string being fully constexpr in C++20. In this article, I like to give you a solid idea of where you can use that.

How does dynamic allocation at compile-time work?

First, let’s ensure that we all understand how dynamic allocations at compile-time work. In the early draft of the paper ‘Standard containers and constexpr’ [P0784R1], proposed so-called non-transient allocations. They would have allowed us to allocate memory at compile-time and keep it to run-time. The previously allocated memory would then be promoted to static storage. However, various concerns did lead to allowing only transient allocations. That means what happens at compile-time stays at compile-time. Or in other words, the dynamic memory we allocate at compile-time must be deallocated at compile-time. This restriction makes a lot of the appealing use-cases impossible. I personally think that there are many examples out there that are of only little to no benefit.

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.

Coroutine Patterns and How to Use Them: Problems and Solutions Using Coroutines In a Modern Codebase

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

by Francesco Zoffoli

In over 30 years of experience the C++ community have developed patterns that are effective in writing complex systems.  The introduction of coroutines introduced a brand new paradigm, but it changes many of the assumptions of the past. In this talk we'll see common patterns and pitfals that arise using coroutines, and what solutions are needed to address them.

Based on the experience working with a heavily coroutinized codebase, this talk will show a collection of common patterns that arise using coroutines. The patterns will cover from code that the compilers today block, to effectively managing resources with RAII, to the need and risks of synchronization. It will present ways to make the code correct, workarounds to obtain the same outcome, or will warn about potential issues that can arise from such patterns.

The code shown is going to be based on Facebook's Folly implementation of coroutines, but the concepts presented are common across other implementations as well (no previous knowledge of Folly is required).

This talk is perfect for practitioners that already are trying coroutines in their codebase and want to ensure the code they're writing doesn't contain hidden bugs, but also for people that haven't used coroutines yet and they are evaluating introducing them in their codebase.

Do you want to discover the new patterns to write correct code with coroutines? Join us for this exciting talk!