C++17 introduced parallel algorithms, but the current interface prevents heterogeneous systems -- such as personal computers and server nodes with GPUs, smartphones, and embedded System on a Chip -- from taking advantage of parallel computation. Through its clean, algorithmic composition, we believe that the Ranges TS and its proposed extensions offer solutions to these problems, and how well programs perform on heterogeneous platforms.
We will discuss why adopting Ranges will be beneficial for your programs, and once parallelised, how they naturally lend themselves to parallelising your code with minimal changes on your part.

Programming is composition; we compose expressions into statements, statements into functions, functions into modules, modules into programs, programs into systems. Often, the way in which our code is composed is buried in the details. We write glue code that ends up duplicating and spreading out the ways in which our programs are composed. This can obscure the structure of the program and make it difficult to reason about.
In this talk I will describe some common compositional patterns and show how they can (or can't) be made explicit in C++. We'll talk about composition at all levels of a C++ program, with a particular focus on functions and algorithms.
My objective is to give you a new perspective on the structure of your C++ programs and to offer you some terminology to use when talking about the compositional patterns that you use. I also hope to encourage you to make composition explicit in your code when the language allows it, but that is not necessary in order to benefit from this talk.

Trompeloeil is a C++14-first mock object framework. In this talk I will show you how I backported it to C++11. In detail, I will

• Discuss motivation for this work.
• Present a brief overview of the library's features.
• Discuss library- and language-specific changes and support these with code snippets.
• Cover unit testing approaches and multi-platform issues.
• Reveal compromises and limitations to backported functionality.
• Outline alternatives to this approach.
• Answer the question: How do I "port" a C++11 program to C++14?

Over the last 35 years, C++ has remained a constant fixture in the programming landscape. With advancements in the language through C++11, 14, and 17, we've created new dialects that have breathed new life into C++. With C++ Core Guidelines and a rich community of authors and speakers providing guidance on C++, it is easier now to steer clear of problem areas and hopefully stay in the "good parts" of the language.
Or at least, that's what we'd like. In practice, many habits of C++ programmers are unsafe and will be hard to keep working. The triple perils of ADL, ODR, and ABI leave a wide assortment of pitfalls for code maintenance. Many systems happen to work, but perhaps more out of luck than actual correctness.
How do we explain this dichotomy? How is the language better than it ever has been, and at the same time so dangerous and burdened with silent pitfalls and legacy? Can the standard evolve over time to reduce these perils? More importantly: should it?
In this talk I'll remind people of how precarious most C++ code is in the face of change (like advancing to a new language version), and discuss the most fundamental issue facing the committee these days: how to balance between the legacy code of the past and the yet-to-be-written code of the future.

Creating cutting-edge games requires engineering for high performance in order to maximize gameplay features and graphical fidelity. Understanding the cache and memory subsystems is a critical part of this.
This talk provides an overview of some of the relevant issues to consider in this area, and how we can design c++ applications to deal with these issues efficiently. There is a focus on aspects that have been particularly important for our work at Wargaming developing games, but the techniques and approaches are widely applicable.

Writing high-quality error-free C++ code itself is a challenging task, let alone when having to juggle multiple platforms at the same time! In this session, I will talk about many challenges in cross-platform C++ development and how tools can help: what options do I have if my production environment is different than my dev box? Can I be as productive when working with remote Linux machines? Is there any good C++ editor that works consistently on all platforms I work on? How can I efficiently build and debug CMake projects, or even get IntelliSense? How can I easily find and acquire open sourced libraries? Is there an easy way to write and run cross-platform tests? Come to see what Visual Studio 2017, Visual Studio Code, CMake, WSL, Vcpkg and more have to offer to make cross-platform C++ development much easier in this demo-heavy talk.

Getting good performance out of your APIs isn't only about supporting move semantics properly. Especially for APIs used in inner loops, it's important that the API and the implementation co-operate in order maximise performance.
This talk will start with some simple places where a small tweak to an API can potentially double performance, and then show how larger structural changes can speed code by even larger factors. It will also suggest a few places where the standard library can be improved to help.

We’ve all heard horror stories about bugs that were near-impossible to root-cause, and many of us have at least a few stories of our own. Time Travel Debugging (TTD) is a reverse debugging toolkit for Windows that makes debugging these kinds of problems far easier, in both small programs and commercial-scale software like Windows and Office. It enables you to record bugs as they happen, then replay the recording in the debugger afterwards, and use most of the debugger features that are available when debugging a live process.
In this session, I’ll introduce what Time Travel Debugging is and demonstrate both how to record execution of a program and how to debug the resulting recording. We’ll walk through the root cause analysis of some typically difficult-to-solve bugs like memory corruption and API misuse. Finally, we'll look at TTD’s advanced querying capabilities, which let you query information about memory accesses and function calls. As we walk through the examples, I’ll also introduce other, related debugger features that make debugging easier in general, even when not using Time Travel Debugging.