CppCon 2021

Designing good, maintainable classes is a challenge. Sometimes it even feels like there is a decision to make in every single line of code. This talk will help you master this challenge. It will explain …

* … why small classes are beautiful;
* … why it is so important to encapsulate variation points;
* … why inheritance is rarely the answer for customization;
* … how to write good and maintainable constructors;
* … how to make sure class invariants are maintained;
* … how to handle member data;
* … how to write good member functions;
* … how to write good supporting functions;
* … why your private members are not private at all.

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

Designing good, maintainable classes is a challenge. Sometimes it even feels like there is a decision to make in every single line of code. This talk will help you master this challenge. It will explain …

* … why small classes are beautiful;
* … why it is so important to encapsulate variation points;
* … why inheritance is rarely the answer for customization;
* … how to write good and maintainable constructors;
* … how to make sure class invariants are maintained;
* … how to handle member data;
* … how to write good member functions;
* … how to write good supporting functions;
* … why your private members are not private at all.

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

This session is part of the Software Design Track.

The standard library has the type `std::vector`. It is used ubiquitously as a high-performance container. However, it was standardized in the mid 90s and C++ has seen many changes since then. It has been extended with allocators, move semantics, initializer_list, and much more. Can we do better?

We can. It is possible to write a container and a set of algorithms that are more efficient at run time, have simpler implementations, and have easier, more intuitive APIs. Not only that, but we can also make it easy for users to write their own vector-like containers that make slightly different trade-offs for when you need even more performance, and this presentation includes discussion of several such vectors.

We will go through specific examples of these vector-like types and the algorithms that operate on them, and then take from that general principles of software design. We'll look into how we're limited in what we can do by C++ as it exists today and what up-and-coming proposals can make things even better.

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

C++ Modules are a tooling opportunity. For example, a common implementation strategy for compilers is to save on disk the abstract semantics graph (ASG) obtained from elaborating a module interface (exported), to be reused later when that module is consumed (imported). That ASG, an intermediate representation, saves the compiler from repeated work in common scenarios, therefore helps achieve substantial reduction in compilation time. In essence, ISO C++ compilers are practically compelled to acknowledge representations of C++ program fragments other than character streams stored in source files. It is all too tempting to view these ASGs as mere build artifact curiosities. If N compilers, on a given platform, decide to use N different on-disk ASG representation formats then we face a severe problem of developer tools fragmentation. I present, in this talk, how the C++ community can avoid that problem: the desiggn and implementation of formal, compiler-neutral in-memory and persistent representations of C++ programs. These alternative representations allow tools to process C++ programs without needing to master or to replicate the dark art of C++ compiler construction. These representations are available either as open specification, or as C++ libraries. The application opportunities range from automated generation of bindings ("foreign function/data interface") to Just-In-Time compilation of interpreted C++ scripts, and beyond.

The six special member functions. Do you know them all? Do you know when the compiler generates them for you and what they are doing? And most importantly, do you know when they don’t give you what you expect? In this talk I will explain the six special members in detail. We will take a look at the exact circumstances when a compiler would generate these functions, what they are doing by default and when we should deal with them manually. Also, among many other guidelines I’ll explain why we should strive for the Rule of 0, why the Rule of 5 is sometimes unavoidable, and why the Rule of 3 is not obsolete.

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

In this workshop, we will take a look into how Python-style named tuples can be implemented in C++20.
The goal will be to test and implement the following snippet from scratch with modern C++ features.

01 const auto tuple = namedtuple{"price"_t = 42, "size"_t = 1'000};
02 static_assert(42 == tuple["price"_t]);
03 static_assert(1'000 == tuple["size"_t]);
04 static_assert(not [](auto tuple) { return requires { tuple["quantity"_t];}(tuple))

At the end of this session, the audience will have a better understanding of C++20 features such as:
- Concepts
- User-Defined Literals
- New additions to lambdas
- std::fixed_string

Additionally, attendees will get familiar with an expressive way of writing modern C++.

Let's get ready to named all tuples at CppCon 2021!

[1] https://docs.python.org/3/library/collections.html

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

Delayed broadcast

C++ Modules are a tooling opportunity. For example, a common implementation strategy for compilers is to save on disk the abstract semantics graph (ASG) obtained from elaborating a module interface (exported), to be reused later when that module is consumed (imported). That ASG, an intermediate representation, saves the compiler from repeated work in common scenarios, therefore helps achieve substantial reduction in compilation time. In essence, ISO C++ compilers are practically compelled to acknowledge representations of C++ program fragments other than character streams stored in source files. It is all too tempting to view these ASGs as mere build artifact curiosities. If N compilers, on a given platform, decide to use N different on-disk ASG representation formats then we face a severe problem of developer tools fragmentation. I present, in this talk, how the C++ community can avoid that problem: the desiggn and implementation of formal, compiler-neutral in-memory and persistent representations of C++ programs. These alternative representations allow tools to process C++ programs without needing to master or to replicate the dark art of C++ compiler construction. These representations are available either as open specification, or as C++ libraries. The application opportunities range from automated generation of bindings ("foreign function/data interface") to Just-In-Time compilation of interpreted C++ scripts, and beyond.

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

Architectural imperatives due to the slowing of Moore's Law, the broad acceptance of relaxed semantics and the O(n!) worst case verification complexity of generating sequential histories motivate a new approach to concurrent correctness. Quantifiability is proposed as a novel correctness condition that models a system in vector space to launch a new mathematical analysis of concurrency. Analysis is facilitated with linear algebra, better supported and of much more efficient time complexity than traditional combinatorial methods.

In this talk, we present the design and implementation of a lock-free quantifiable stack (QStack) and a lock-free quantifiable queue (QQueue) in the C++ programming language. Our design achieves lock-freedom using compare_exchange_strong from the C++17 Atomic Operations Library. We depict several code snippets that illustrate how quantifiable data structures are highly scalable through use of relaxed semantics, an explicit implementation trade-off permitted by quantifiability. We explain how to reason about the correctness of quantifiable data structures and present a technique and a dynamic analysis tool developed in C++ for efficiently verifying a concurrent history as quantifiably correct, referred to as Vector Space Verification (VSV). We illustrate why it is impractical to use alternative verification techniques that compare concurrent histories to sequential histories for determining correctness for real programs.

We showcase the performance of quantifiable data structures by presenting a live demonstration that runs the QStack and QQueue and plots the results in real time. The QStack is compared with the lock-free Elimination Backoff Stack and the lock-free Treiber stack. The QQueue is compared with the lock-free LCRQ, and the wait-free Fetch-And-Add queue. The live performance demonstration illustrates how the QStack and QQueue achieve substantially higher scalability than the state-of-the-art linearizable counterparts. We also present a live demonstration of our VSV tool to dynamically check a concurrent history for the QStack and QQueue as quantifiably correct in less than O(n^2) time.

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

C++ class design has been error prone since the beginning until Scott Meyers told us about the Rule-of-Three. But even that is not enforced by the language. In addition, C++11 changed the set of compiler-provided special member functions and the intrinsic rules have become more complicated. However, instead of starting from the rules for special member functions, we will look at what role a class type plays and how that maps on what special member functions to define and how, if any. Examples for class roles are Value, Relationship, Manager (scoped, unique, general), Mix-in.

We will also look at the roles of member variable types that influence or imply the role of the class type.
The role of a class will also take out many mysteries of move operations and will lead to clear guidance when and how to implement move: for suppressing copying, for managing unique ownership (Unique Manager) or for optimizing object copies (General Manager).

We will rehearse the Rule of Zero, and learn more about the Rule of Five/Six, the Rule of DesDeMovA, and the Rule of Unique Three.

This all will enable you to much more consciously and safely design your class types and combine types of member variables. You will have then the ability to select from a few reasonable combinations from the plethora of possibilities of special member function combinations: {public:,protected:,private:} x {destructor, default constructor, copy constructor, copy assignment, move constructor, assignment} x {noexcept(true),noexcept(false)} x { =default, =delete, {/*body*/}, not declared } (math as homework)

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

Emerging byte-addressable Non-Volatile Memories (NVMs) provide higher densities and data persistence where process state can be recovered after crashes. Graph analytic applications such as search and ranking, pattern matching, and clustering benefit from the large capacity available with persistent memory since the data sets are very large with up to trillions of vertices and edges. A hash map is fundamental for graph analytics because it associatively map keys to values, offering constant time lookup for graph updates. While lock-free persistent hash maps have been developed, most perform poorly due to a heavy use of pointer dereferences. Additionally, it is often desirable to perform a composition of graph updates as a transaction. Although persistent data structures enable applications to rely on persistent data with failure-atomic operations, they lack the ability to allow users to execute a sequence of operations as transactions. Meanwhile, persistent transactional memory (PTM) has been proposed by adding durability to Software Transactional Memory (STM). However, PTM suffers from high performance overheads and low scalability due to false aborts, logging, and ordering constraints on persistence.

In this talk, we present PMap, a persistent concurrent hash map with open addressing and non-blocking parallel resizing to cater to large graph processing workloads. Our PMap achieves lock-freedom using compare_exchange_strong from the C++11 Atomic Operations Library. To provide persistence, our design uses a modified version of the link-and-persist approach. While this approach is traditionally used to persist pointers, our modification enables link-and-persist to be used in-place, persisting keys and values directly. This is crucial, as logs, or separate object allocations may require pointer dereferences, which undermines the cache locality benefits of pure open addressing. The PMap uses the C++11 alignas specifier to ensure data can be aligned and flushed on a per-cacheline basis into persistent memory. To accommodate durable transactions, we present PETRA, a new approach for constructing persistent transactional non-blocking linked data structures. PETRA natively supports transactions, but unlike PTM, relies on the high-level information from the data structure semantics. This gives PETRA unique advantages in the form of high performance and high scalability. We present diagrams detailing the PMap design and PETRA methodology for the C++ programming language, and illustrate how to keep the number of cache line flushes and memory fences low through the use of descriptor objects, which are commonly used in the design of lock-free data structures.

We showcase the performance of our proposed persistent data structures by presenting a live demonstration of PMap and PETRA data structures including a linked list, skiplist, map, and multi-dimensional list. We compare PMap to clevel, OneFile, STL, and PMDK, tested on a micro-benchmark and on files from Recursive Model for graph mining (R-MAT). We compare the PETRA data structures to OneFile, Romulus, and PMDK, tested on a micro-benchmark and the Telecommunication Application Transaction Processing (TATP) benchmark. The live demonstration illustrates how PMap outperforms state-of-the-art alternatives averaging 3122x faster under Intel Optane DC, and PETRA outperforms the state-of-the-art PTMs by an order of magnitude in transactions of size greater than one, and demonstrates superior performance in transactions of size one.

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/

How do you change the active member of a union? Can you copy an object without
a publicly callable copy constructor? Can you pass classes having private data to
a function implemented in C? What is the use case for the library type trait
`std::is_trivially_move_assignable`? All these questions and more will be answered
in this session.

PODs --- Plain Old Data --- are neither plain nor old in C++11, and continued to
evolve in every published standard since, until they were finally banished in C++20.
In researching the deconstruction of PODs for the upcoming book, "Embracing
Modern C++ Safely" Alisdair Meredith (and the other authors including John
Lakos, Vittorio Romeo, and Rostislav Khlebnikov) discovered that many of the
intuitive properties and capabilities of trivial and standard layout types did not
behave quite as expected, and there are many subtleties waiting to catch the
unwary. Nina Ranns, as an active member of the Core working group, stepped in
to explain and resolve many concerns, while pointing out further bad assumptions.
Together they will present the use cases, pitfalls, and annoyances of these features
as now properly understood, giving a flavor of the presentation style of each of the
57 C++11/14 features presented in the book.

ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY: https://cppcon.digital-medium.co.uk/