CppCon 2019

You've inherited some legacy code: it's valuable, but it doesn't have tests, and it wasn't designed to be testable, so you need to start refactoring. But you can't refactor safely until the code has tests, and you can't add tests without refactoring! How can you ever break out of this loop?

Whether Legacy code for you means "old code", "code without tests", or "code you wish to redesign for new features or unit-tests", this talk will enable you to become productive and work safely, quickly.

The simplicity, convenience, ease-of-use, power and flexibility of Llewellyn Falco's "Approval Tests" approach has long been proven in a dozen programming languages. And now all this is now available to C++ developers too!

Clare will present a small but surprisingly effective C++11 library for applying "Approval Tests" to cross-platform C++ code - for both legacy and green-field systems, and with a range of testing frameworks.

She will describe its use in some real-world situations, including how to quickly lock down the behaviour of legacy code. She will show how to quickly achieve good test coverage, even for very large sets of inputs. Finally, she will describe some general techniques she learned along the way.

Attendees will discover some quick, practical techniques to use for common challenges, such as testing outputs containing dates and times, that can be applied very easily using Approval Tests.

When we first learn how to write programs, especially how to handle errors, we are given lots of advice saying do this, don't do that. Sometimes with rationale and sometimes not; but it is often difficult to make mental model that would make it easy to understand why we are doing it this way and not another, and why we have to follow this and this rule.

In this talk I will share an important observation: error handling -- be it error codes, errno, exceptions, error monad -- is about cancelling dependent operations. If we understand this, lots of recommended practices immediately start to make sense and become intuitive.

One of the reasons why a lot of us work in C++ is because there is a huge amount of existing projects written in C++.

But existing code can be hard to understand.

In this presentation, you will learn how to make sense of code quickly, from the general big picture of the codebase all the way down to the little details of the code of a complex class.

The ten rules covered in this session will teach you to:
- start reading code from the end
- identify the parts of code that carry the most information
- locate the code of any feature visible in the application
- and many more!

Code reading techniques usually come with years and years of experience. This presentation will teach some of them to you right now, supported by code examples.

There is a wealth of talks about how to write C++ code using the latest features of the language, but there are very few talks about reading existing code. In particular the everyday code that people have in their codebases. And as the saying goes, code is read much more often than it is written.

This presentation aims at filling this need in a practical way, by exposing 10 techniques that conferences attendees can use on an everyday basis to understand quickly the code they get to work on, as soon as they go back to the office after the conference.

Higher levels of abstraction are useful for building things out of, but also have a higher cognitive and maintenance cost. That is, it's a lot easier to refactor a function than it is to change a type, and similarly easier to deal with a single concrete type than a class template, or a Concept, or a meta-Concept ... In this talk I'll present example strategies for refactoring the interface of functions, classes, and class templates. I'll also discuss how the recent addition of Concepts and the proposals for even-more-abstract features affect long-term refactoring in C++. If you're interested in refactoring and it isn't immediately clear that a Concept published in a library can never change, this talk is for you.

Just how different is "Modern C++" from "legacy C++"? Is my codebase ready for C++17? Do I need a full rewrite of my app to have modern C++ code? If you're looking for answers to some of these questions, join us for a session on how to effectively add modern C++ features in your existing C++ projects by taking advantage of the latest developer tools for C++ from Microsoft; and no, you don't need to rewrite you app…

When you have thousands of C++ services and you've just changed a core library, how do you make sure nothing broke? In 2016 we explored what that looks like from the perspective of the engineer changing the library (https://youtu.be/_YzUD9FvQlg). Now we're going to look at that same problem from perspective of an engineer working on developer experience, providing that safety, all the while trying to make sure we don't break the bank in machine costs. We'll notice patterns, including how saving machines nearly always means saving developer time and making build/test signal less flaky and more trustworthy. Better savings, better experience.

Most practically for you: we'll go over what can you do in your codebase to improve your testing workflows, ranging from low commitment concepts to high commitment ones. Also importantly: what anti-patterns can you avoid, so that you don't blockade future work in this area.

Our exploration will take us across topics including build tools, how the compiler/linker fits into the story, caching in unexpected places, deciding what to test (in great depth), batching, patterns/anti-patterns for defining workflows, and more. We will talk about real learnings from metric-driven changes to our core continuous integration experiences.

Unit testing is a widely accepted practice in the software engineering industry, which has been demonstrated to help reduce bugs in production and provide faster iteration cycles for development, helping with development trends such as agile development or continuous deployment.

While being part of the core of modern development, C++ due to its current language limitations lacks a unit testing framework that's expressive and concise enough to keep developers focused around tests themselves and not around all the code needed to support the tests. Current unit testing solutions for C++ usually require arcane constructions through macros, intrusive changes in the tested codebase in the form of class hierarchies for easy mocking, and in some cases manual test registration.

I present unittest, a proof of concept unit testing framework for C++14 based on Python's standard unittest package. unittest avoids the problems described above by using static reflection to figure out what code describes a unit test, and what library functions should be mocked as part of the test. Current C++14 implementation is based on tinyrefl, a libclang based static reflection tool, but the same concept will be possible to implement through future C++ reflection features like those proposed by the Reflection Technical Specification.

The ABI (Application Binary Interface) has a huge impact on C++ libraries. But what does that mean concretely?

This talk will explain what we mean by the ABI in the context of C++. Starting from the ground up and focusing on the Itanium C++ ABI specification, we will understand what is part of the ABI and how changes in your C++ source code can result in changes to the ABI. We will also cover what ABI stability means, what use cases ABI stability enables, and what some of the costs of maintaining ABI stability are.

Keeping the point of view of a library implementer, we will see how one can control what is part of a library's ABI, using both standard and non-standard techniques like attributes. Finally, we will also see some tools that can be used to inspect parts of the ABI of a built program and detect changes to it.

As a community we've tried many different ways to express, propagate and handle error conditions in our code over the years. Each seem to have different trade-offs, with none being perfect in all cases.

This presentation is the follow-up to my earlier talk, "Option(al) Is Not a Failure", where I surveyed existing error-handling approaches and score them against each other, leading up to the new proposal, p0709, "Zero-overhead deterministic exceptions".

We'll summarise some of that background so we're all on the same page, but in this talk we're going to dig into the proposal in more depth - and look at the supporting proposals, p1028 (std::error) and p1029 ([[move relocates]]) and others. We'll also comment similar mechanisms in other languages, notably Swift, to get an idea of how it might work out in practice.

“If you’re arguing, you’re losing”, or so said Dan Saks when discussing migrating legacy C codebases to C++. Many of the arguments that you hear against using C++ deal with the level of abstraction provided by objects and the STL (or templates, in general). However, there are many standard practices in C codebases that can benefit from some C++ tactics without having to introduce any of those features of the language. In this talk, we will look at some history of C to understand the viewpoint of C programmers. Then we will see methods to both improve both the reliability and maintainability of the codebase, while not alienating the existing developers. Along with these techniques, we will use compiler output that can be used to prove that we aren’t introducing any new overhead. Armed with these tools, we can move this legacy code and your team forward in preparation for the day where the file is renamed from C to CPP.

The oft-cited Hyrum's law states that "with a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." With the introduction of concepts as a language feature in C++20, generic programming is expected to make its way into more layers of software stacks than ever before. Employing concept-driven design across multiple layers of a software stack affords a number of new and innovative approaches to battling Hyrum's law. As more and more libraries are tested and deployed with contracts expressed through generic concepts, a new art of providing models of those concepts that stress the boundaries of the contracts they represent is emerging. Put simply, it's more important than ever to break things early and often.

Unlike interfaces based on concrete types and abstractions, where a single interface is generally tied to a single implementation (thus leading to leaking of implementation details into an implicit interface), concept-driven interface designs can more naturally provide multiple implementations that model a concept, and thus constrain the implicit interface to the overlap of those implementations. Designing and implementing sets of types that minimize this intersection is a crucial skill that should be in every advanced developer's toolbox, and yet it is rare to hear this "art of breaking things" addressed explicitly.

In this talk, we will examine the implementation of several common interfaces that can be expressed with concept-driven design, including ranges, futures, strings, spans, and executors. Within a typical set of contracts for these concept interfaces, we will work through the design and implementation of models for these concepts focused on breaking user code that unsafely widens these contracts. We will further motivate these examples with some real-world scenarios and weigh the importance of breaking things against other factors in generic library design. Finally, we will discuss how the ability to break things should feed back into the concept design process itself, leading to more robust and less implicit interfaces throughout your software stack.

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.

A fundamental reason why C++ is successful and loved is its adherence to Stroustrup’s zero-overhead principle: You don’t pay for what you don’t use, and if you do use a feature you can’t reasonably code it better by hand. In the C++ language itself, there are only two features that violate the zero-overhead principle, exception handling and RTTI – and, unsurprisingly, these are also the only two C++ language features that every C++ compiler has switches to turn off and that are regularly discouraged or even banned. This matters because not using these features is the largest current cause of fragmentation of the C++ community into incompatible dialects, and the cause of recurring problems including type confusion security vulnerabilities arising from “didn’t down-cast using dynamic_cast because that would be too slow.” This talk is about ongoing long-term efforts to try to unify the community in this area, not by replacing exceptions and RTTI, but by doubling down: fully embracing exceptions and RTTI, and improving them so they can be zero-overhead too.