C++Now 2019

Complex domains with volatile concerns are increasingly converging on “declarative” APIs to provide a consistent and high-level abstraction from which the developer may reason about system status, configuration, and behavior. Declarative APIs present an illusion of simplicity and consistency, hiding the volatile transformations that occur within the running system, and the edge cases and interactions among coupled concerns. A declarative approach is especially well-suited to remain stable, while permitting the internal system behavior to change implementation and evolve over time.

A “declarative container” similarly presents this illusion of consistency, and simplicity: Properties are extracted to describe the contents of a container, but the container implementation remains opaque. This presents an interface independent of the data layout and possibly evolving algorithms used to maintain invariants within that container.

Declarative containers are in contrast to C++ std:: containers which are decidedly non-opaque. Whereas the std:: containers guarantee data layout and specify Big-O traversal complexity, a declarative container is assumed to be opaque, and is interrogated only through property extraction. As a result: Algorithms express differently, because the declarative container interface is not based on item iteration.

We discuss a unified model of declarative property-based containers that provide the expressive simplicity of a declarative API, while still enabling the efficiency and control offered through std:: containers, iterators, and algorithms. The declarative container opaquely aggregates domain-specific types, and we explore the authoring of domain-specific algorithms reliant upon the properties exposed by the container. No iterators are invalidated or harmed in this process (and indeed, iterators serve no purpose whatsoever in the declarative container interface).

The performance benefits of supplying local allocators are well-known and substantial [Lakos, ACCU’17]. Still, the real-world costs associated with orchestrating the integration of allocators throughout a code base, including training, supporting tools, enlarged interfaces (and contracts), and a heightened potential for inadvertent misuse cannot be ignored. Despite substantial upfront costs, when one considers collateral benefits for clients – such as rapid prototyping of alternative allocation strategies – the case for investing in a fully allocator-aware (AA) software infrastructure (SI) becomes even more compelling. Yet there remain many “concerns” based on hearsay or specious conjecture that is either overstated or incorrect.

In this densely fact-infused talk, we begin by introducing a familiar analogy to drive home the business case for AASI. Next we identify four syntactic styles based on three distinct models: C++11, C++17, and a brand new language-based approach being developed by Bloomberg for C++23 (or later). Costs – both real and imagined – will be contrasted with performance as well as other important (“collateral”) benefits. The talk will conclude with a closer look at the economic imperative of pursuing a low-cost language-based alternative to AA software in post-modern C++.

This session will provide an introduction to pmr::test_resource, which supports testing memory allocation related behavior on a per-object basis.

pmr::test_resource is a C++17 memory resource designed for testing that can be plugged into any test framework. It is the modernized version of the bslma::TestAllocator used in production for over two decades at Bloomberg, where it has helped to expose a variety of bugs, such as memory leaks, overruns, multiple deletes, exception-safety guarantee failures etc. This presentation will show the use of test_resource in detecting errors related to memory allocation. We walk through code to demonstrate several bugs and show how they misbehave, how we diagnose them, and a reasonable fix. pmr::test_resource is being proposed for the Library Fundamentals 3 TS and full
source code for test_resource, bslma::TestAllocator and the examples is available on GitHub.

This talk will present the current state of my work on designing and implementing Physical Units Library for C++. I will present all the challenges, design tradeoffs, and potential solutions to those problems. During the lecture, we will also see how new C++20 features help to make the library interface easier to use, maintain, and extend. Among others, we will see how we can benefit from class types provided as non-type template parameters, how new class template argument deduction rules simplify the interfaces and the full power of using concepts to constrain template types.

One way of modeling a procedure mathematically is to treat it as a statement about the ways in which events can be arranged by a computer. This conception brings programming into the domain of mathematical logic, the study of truth and proof in formal languages.

In this lecture, I will explain how to read a procedure and its interface as a sentence, how that sentence may be true or false, possible or impossible, necessary or provable.

This presentation of programming from a logician’s perspective is intended to complement the topologist’s perspective of last year’s keynote, “The Shape of a Program,” but is independent of the material covered there.

Can't we just add a functional programming language to C++ as a DSL that integrates seamlessly? Would that be a good thing? Would I have to understand category theory to use it? Whether or not you are a fan of domain-specific languages it seems we are getting one in C++20's standard library. The ranges DSL brings with it some high-level concepts and with a little abuse many more concepts, from functional programming. At the same time, there seems to be interest in other DSLs bringing other functional concepts such as monadic extensions to optional or monadic composition of asynchronous tasks. But why in separate DSLs? This seems odd because unifying things is at the very heart of functional programming.

In this talk, I will make the argument that with 3 small extensions to the ranges DSL syntax we can make one DSL to rule them all lifting may existing C++ language and library features into a more functional or declarative paradigm as well as unifying many boost libraries. After refreshing the core concepts of the ranges DSL and presenting my proposed extentions we will take a whirlwind tour of how I think we should add functional programming paradigms to C++ in a unified manner. We will rethink sum types, fusion metaprogramming, event-based programming, monads, Haskell do notation, closure's transducers, rust's match, named/deduced parameters, state machines, "terser" lambda syntax, pointfree programming, generative programming, and declarative programming paradigms.  

Today, almost every computer, tablet and phone comes with audio input and output. Computer games and many other kinds of applications would be unthinkable without sound. Yet, the C++ language has no notion of it. Literature on audio in C++ is sparse. For even the simplest possible audio functionality, programmers need to deal with a confusing landscape of complex platform-specific APIs and proprietary 3rd party libraries. But audio in C++ doesn't have to be hard!

First, we show how audio signals can be digitally represented in C++, covering basic concepts such as channels, audio buffers, PCM, and sample rate. We explain the principles of communicating with your soundcard and playing, recording, reading and writing audio data. In the second half of the talk, we will discuss a proposal to add a minimal, modern audio API to the C++ standard library. We will show the basic design, the current state of the implementation, and simple example apps. We finish with an update on the current state of this proposal.

This is an information/work session for the C++Now Program Committee.

We will discuss the review the Reviewers' Guide ways to improve our process and product:
https://docs.google.com/document/d/1Z1PXETemPj0FP_i_zqt1YFHK4KiFYAiGTvbpVa2kKE0/edit?usp=sharing

Note: Boost will cater this meeting for attendees that sign up in advance. Sign up here and indicate that you are attending the PC meeting. 

Before we can make the use of formal interfaces routine, we must develop not only the mathematical theory, but also the programming practice. Practice, of course, is developed by working out examples.

In this presentation, I will work out formal interfaces for a number of familiar functions and try to draw out some lessons about writing practical interfaces.

This presentation will refer to my earlier presentation “The Truth of a Procedure” occasionally, but should be understandable to those who missed it. The examples will be given in a notation similar to that of my presentations in previous years, “What is the Basic Interface?” “Locally Atomic Capabilities and How to Count Them,” and “The Shape of a Program.”

C++ is a notoriously difficult language to master and Modern C++ is not far behind it. The language itself is powerful and flexible but does little to protect us from using it incorrectly and the closer a vulnerability is to an attack surface, the more easily it can be exploited. But how do you know where your attack surfaces are?

Threat Modeling is the foundation of everything else we do when securing our code. It tells us where the attack surfaces are, what possible attack vectors there are, where we aren't verifying who we're communicating with, where we're holding data and more importantly where we're holding data we don't use. Threat modeling forces us to analyze our designs & code by focusing our thinking to that of an attacker. Without it we have little to go on when looking for areas of vulnerability.

In this talk, we'll begin by looking at Intrusion Kill Chains, a simple but effective way to describe the process that attackers use to penetrate systems. We'll look at one of the most famous and successful attacks in cyber history through the lens of a kill chain.

Using this knowledge we'll then do a hands-on Threat Modeling exercise against an everyday system designed in Modern C++ using the STRIDE approach (and discuss others as we go). We'll look at:

how Spoofing can be used to gain unauthorized access to data within our system,
how Tampering is used to affect system behavior and how to protect against it,
how Repudiation is used to ensure that all systems behavior is verified,
how Information leaks give an attacker vital information on how to attack our systems,
how to defend against Denial of service attacks, and
how privilege Escalation attacks give attackers access to more than just our systems.


We'll also discuss how we have come to live in a Zero Trust world and how that affects systems design. We'll see how Threat modeling allow us to:

expose attack surfaces,
uncover architectural flaws early,
identify attack vectors,
balance risks and usability, and
document mitigation strategies.


Modern C++ is a powerful, flexible language, but it's not safe for those who have not truly mastered it. And as systems complexity increases, those knowledge gaps leave openings for attackers. Threat Modeling is the first step in sealing those gaps.

For the past 30 years, we have dealt with penetrations into secure systems almost exclusively from the software layer: applications and operating systems. With the advent of side channel attacks like Spectre, Meltdown and Foreshadow, hardware designs are now battlefields.

For C++ and Modern C++ engineers who run close to the hardware, whether they work in the embedded world or not, the implicit trust between our code and the hardware is absolute. In this talk, we'll look at how hardware has become the newest targets for the next generation of attackers and how that affects Modern C++ systems design. Then we'll see how hardware exploit strategies drive software exploit strategies in Modern C++.


We begin with a discussion of the concept of Roots of Trust and how each successive layer forms the Root of Trust for the layer above. But what are Roots of Trust and how can a failure at one level be used to create vulnerabilities in each successive layer? For Modern C++ systems, over reliance on the implicit trust of the layers below can spell disaster. But how does one layer protect itself against the broken trust of another?

Next, we'll see that side channel attacks are really a class of attacks that involve involuntary information disclosure. Spectre, Meltdown and Foreshadow are just one facet of those types of attacks. We'll look at how hardware side channel attacks that are run against hardware timing, current draw and memory all provide attackers invaluable information on the design and performance of a system. Then we'll see how these same types of attacks can be run against Modern C++ systems by profiling a running system.

We'll then discuss how having physical access to the hardware creates opportunities for attackers to design attacks that succeed at a distance. Physical penetrations range from probing data buses and pins to looking for emitted photons to tearing apart ICs. The exploitation of the hardware becomes the Achilles heal of the higher software layers because of their dependence in the hardware. But it also tells us something about the strategy for reverse engineering Modern C++ systems both in their behavior and their design. Understanding the strategies for reverse engineering software and source code shows us how to change our software designs and architectures to harden the target.

Finally, we'll discuss how hardware supply chains create opportunities for nation states to build in back doors for controlling systems at a distance. We'll see how Quality Assurance programs designed to catch tampering can be defeated by the careful selection of techniques and by simply playing the odds. We'll see how the strategies for testing are evolving to confront this new reality. And we'll look at how securing the supply chains of the future points us toward securing the supply chains in Modern C++, namely open source libraries.

Along the way, we'll see:

how C++ designers can defend against the failure of Root of Trust that's been in place for decades,
how software and hardware designs are changing to address these new threats,
how the compromises of the hardware supply chains mirror the compromises of the open source software industry, and
how the lessons learned in hardware exploitation affect the design of Modern C++ systems.

For C++ developers, understanding how the hardware layer can be compromised presents new challenges and has profound implications on the design and implementation of Modern C++ software systems.

High-Frequency Trading (HFT) and low-latency trading are a major preserve of C++. The fact that it is amenable to extensive optimisation, including micro-optimisations, has made C++ highly effective. Moreover C++ can be very low-level to these micro-optimisations can make use of the specific machine architecture. Also the impact the O/S upon such performance-critical systems will be investigated.

This updated talk has results from some of the latest versions of G++ and Clang on Gentoo!

This talk shall investigate the use of micro-optimisations, initially via the generated assembly from versions of g++, clang and icc, then the performance of the micro-benchmarks will be investigated. These micro-optimisations will be brought together into a simple yet extremely fast FIX-to-MIT/BIT trading system for which various factors that could affect the performance shall be presented. Initially the impact of the compiler shall be analysed then affect of the O/S upon the performance of this trading system (with surprising and hopefully informative results!), followed by the affect of changing hardware. Finally the impact of the mitigations for Spectre and Meltdown shall be investigated with respect to various O/Ses - which may appear to contradict the currently-propounded beliefs of some major organisations.

The conclusion shall extract considerations that I consider key to the development of highly micro-optimised software.

One of the largest and widest-reaching library design efforts undertaken by the ISO-C++ standard committee in recent years is the proposal of a generic abstraction for execution, known as an executor. Dating back to at least 2012, the effort to design an executors library for standard C++ has come to a head recently with its inclusion in the list of priorities for the C++20/23 timeframe. The effort to construct a concept-driven design that meets the needs of vastly different domains with vastly different approaches to execution and vastly different needs is one of the most ambitious generic programming exercises of its kind ever. In the past year in particular, the executors design effort has undergone significant changes to accommodate the needs of yet another domain and yet another perspective on execution. The authors of the proposals have had to invent new mechanisms for expressing the vast outer product of behaviors, semantics, performance hints, and other properties of executors in generic contexts.

While very few (if any) design efforts require the level of genericness and customizability that executor standardization demands, many of the lessons learned from the ongoing saga of executor design can be applied to any generic programming project. In addition to an update on the progress of ISO-C++ executors and a history of the design effort, this talk presents a discussion of the general principles of concept-driven design that can be extracted from the executors experience thus far. Additionally, this presentations goes into detail on the latest design iterations and outlook for executors, futures, and other concurrent programming abstractions in C++23 and beyond.

C++ offers two-ish smart pointer types, std::unique_ptr＜＞ and std::shared_ptr＜＞, with their own advantages and disadvantages. But what if these didn't exist, and your company wanted to create smart pointers to capture ownership semantics? Pure Storage had to create smart pointers for ourselves in 2009, and we rarely use the C++ smart pointers. I will discuss the semantics of our smart pointers: owned＜＞ and delete_ptr＜＞, the conventions we have regarding them, and how they differ from C++'s offerings. owned＜＞ has some advantages over unique and shared pointer, including the fact that changing from single ownership to multiple ownership doesn't change the name of the type, unlike unique -＞ shared.

We have additional derivations from the basic owned＜＞ type that express ownership but also separate the view of the data from the ownership; this also has similarities to how the C++ smart pointers allow for a Deleter that is separate from the specified pointer type.

CMake is a cross-platform build system that is used by a large portion of the open source C++ community, yet Boost still uses a build system that is largely unknown. No doubt, transitioning to CMake will help make Boost more accessible and bring in a larger community of support. Its time for Boost to take the plunge.

In this talk, we will discuss the different needs of users for CMake in Boost, the structure of CMake scripts to support such users, a look at Boost CMake modules to help improve CMake build scripts, and a migration path to move to CMake.

If you’re looking for a fast and lightweight open-source code editor, Visual Studio Code has you covered. Come for a deep dive of Visual Studio Code features which provide a rich, productive environment for C++ development. Features will be presented live so you can see how they can aid your day-to-day editing, building and debugging.