Inside STL: The array

By Raymond Chen

template<typename T, size_t N>
class array
{
    T elements[N];
};

template<typename T>
class array<T, 0>
{
};

The only weird case is N = 0. You are allowed to create a zero-length std::array, but C++ does not allow zero-length C-style arrays. The zero-length std::array is just an empty class.

Visual Studio and the Windows debugger come with a visualizer:

0:000> dx a
a                : { size=5 } [Type: std::array<int,5>]
    [<Raw View>]     [Type: std::array<int,5>]
    [0]              : 3 [Type: int]
    [1]              : 1 [Type: int]
    [2]              : 4 [Type: int]
    [3]              : 1 [Type: int]
    [4]              : 5 [Type: int]

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.

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.