Inside STL: Smart Pointers

By Raymond Chen

The C++ standard library comes with a few smart pointer types.

The simplest one is unique_ptr: This class babysits a raw pointer and remembers to delete it at destruction (in an appropriate manner). Dumping the contents of a unique_ptr is just looking at the raw pointer inside.

The complication is that there is also a deleter object in the unique_ptr. This deleter object is usually an empty class, so it is stored as part of a compressed pair.

The Visual Studio debugger has a visualizer that understands unique_ptr, but here’s what it looks like at a low level in the Microsoft implementation:

0:000< ?? p
class std::unique_ptr<S,std::default_delete<S> >
   +0x000 _Mypair          : std::_Compressed_pair<std::default_delete<S>,S *,1>
0:000< ?? p._Mypair
class std::_Compressed_pair<std::default_delete<S>,S *,1>
   +0x000 _Myval2          : 0x0000020a`11f08490 S
0:000< ?? p._Mypair._Myval2
struct S * 0x0000020a`11f08490 ← here is the unique object
   +0x000 a                : 0n42

Back to Basics: Algorithms

Tuesday, October 3 • 09:00 - 10:00

by Klaus Iglberger

“There was never any question that the [standard template] library represented a breakthrough in efficient and extensible design” (Scott Meyers, Effective STL, 2008)

Originally developed as part of the Standard Template Library (STL), algorithms have become a must-know tool for every C++ developer. They increase productivity, significantly reduce bugs, and improve maintainability. This talk explains why and how algorithms do this. Additionally, it demonstrates why they are an amazing example for good, extensible software design.

Express Your Expectations: A Fast, Compliant JSON Pull Parser for Writing Robust Applications

Tuesday, October 3 • 09:00 - 10:00

by Jonathan Müller

There are, by now, several well-established C++ JSON libraries, for example, boost.JSON, rapidjson, and simdjson. C++ developers can choose between DOM parsers, SAX parsers, and pull parsers. DOM parsers are by design slow and use a lot of memory, SAX parsers are clumsy to use and the only well-known pull parser simdjson does not fully validate JSON documents and also has high non-constant memory usage. Our open-source JSON parser fills the gap between the existing parser libraries. It is a fully validating, fast, pull parser with O(1) memory usage.

Its main contribution, however, is the API design. All existing parsers verify that a parsed document is valid JSON. But most applications require the data to have a specific structure, for example, that an object has specific required keys while other keys may be optional. Their associated values in turn are expected to be, for example, strings, objects or arrays. Currently, developers need to implement their own checks and their own error handling on top of the existing parser APIs.

Our API forces developers to express these semantical constraints, providing automatic error handling in return. The resulting code concisely documents the required JSON structure and always handles errors correctly. We have found this to be extremely useful in practice.

This talk will show the JSON parser API in practice, compare it to the established parsers, and will demonstrate some elegant generic programming C++ techniques to beginners and intermediate C++ developers.

Exceptionally Bad: The Story on the Misuse of Exceptions and How to Do Better

Tuesday, October 3 • 09:00 - 10:00

by Peter Muldoon

Exceptions were originally heralded as a new modern way to handle errors. However the C++ community is split as to whether exceptions are useful or should be banned outright. It has not helped the pro-exception lobby that in their enthusiasm to embrace exceptions, a lot of code has been written that puts exceptions in a bad light.

In this talk, We will present the original intent/history of exceptions and a brief overview of how exception mechanics work and how they circumvent the usual stack return mechanism to set the stage. we will then examine the philosophy of using exceptions and then the many cases of exception misuse including resource management, retries, hierarchies, data passing and control flow to name but a few.

For each case, we will then suggest better ways to handle each specific situation. In many cases, exceptions are often dropped in favor of some other more appropriate paradigm.

Finally, we will introduce situations that can truly benefit from exceptions and what a model exception class might look like.

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.

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.