CppCon 2017 Sessions (Audio)

The feature set for the C++17 release is set, and the release of the standard is just around the corner. In this session, we'll discuss all the new C++ features in C++17 and how they'll change the way we write C++ software. We'll explore the new standard in breath, not width, covering a cornucopia of core language and library features and fixes: Language Changes (part 1): Structured bindings Selection statements with initializers Compile-time conditional statments Fold expressions Class template deduction auto non-type template parameters inline variables constexpr lambdas Unary static_assert Guaranteed copy elision Nested namespace definitions Preprocessor predicate for header testing Library Changes (part 2): string_view optional variant any Parallel algorithms Filesystem support Polymorphic allocators and memory resources Aligned new Improved insertion and splicing for associative containers Math special functions Variable templates for metafunctions Boolean logic metafunctions

The feature set for the C++17 release is set, and the release of the standard is just around the corner. In this session, we'll discuss all the new C++ features in C++17 and how they'll change the way we write C++ software. We'll explore the new standard in breath, not width, covering a cornucopia of core language and library features and fixes: Language Changes (part 1): Structured bindings Selection statements with initializers Compile-time conditional statments Fold expressions Class template deduction auto non-type template parameters inline variables constexpr lambdas Unary static_assert Guaranteed copy elision Nested namespace definitions Preprocessor predicate for header testing Library Changes (part 2): string_view optional variant any Parallel algorithms Filesystem support Polymorphic allocators and memory resources Aligned new Improved insertion and splicing for associative containers Math special functions Variable templates for metafunctions Boolean logic metafunctions

C++ solves the problem of runtime polymorphism in a very specific way. It does so through inheritance, by having all classes that will be used polymorphically inherit from the same base class, and then using a table of function pointers (the virtual table) to perform dynamic dispatch when a method is called. Polymorphic objects are then accessed through pointers to their base class, which encourages storing objects on the heap and accessing them via pointers. This is both inconvenient and inefficient when compared to traditional value semantics. As Sean Parent said: Inheritance is the base class of evil. It turns out that this is only one of many possible designs, each of which has different tradeoffs and characteristics. This talk will explore the design space for runtime polymorphism in C++, and in particular will introduce a policy-based approach to solving the problem. We will see how this approach enables runtime polymorphism with stack-allocated storage, heap-allocated storage, shared storage, no storage at all (reference semantics), and more. We will also see how we can get fine-grained control over the dispatch mechanism to beat the performance of classic virtual tables in some cases. The examples will be based on a real implementation in the Dyno library [1], but the principles are independent from the library. At the end of the talk, the audience will walk out with a clear understanding of the different ways of implementing runtime polymorphism, their tradeoffs, and with guidelines on when to use one implementation or another. [1]: https://github.com/ldionne/dyno

The proposed range concepts for the standard library are a significant improvement but are designed for the mental model of iterating and mapping values, not hierarchical domain decomposition. Even for a seemingly trivial array there are countless ways to partition and store its elements in distributed memory, and algorithms are required to behave and scale identically for all of them. It also does not help that most applications operate on multidimensional data structures where efficient access to neighborhood regions is crucial. Among HPC developers, it is therefore widely accepted that canonical iteration space and physical memory layout must be specified as separate concepts. For this, we use views based on multidimensional index sets, inspired by the proposed range concepts. In this session, we will explain the challenges when distributing container elements for thousands of cores and how modern C++ allows to achieve portable efficiency. As an HPC afficionado, you know you want this: copy( matrix_a | local() | block({ 2,3 }), matrix_b | block({ 4,5 }) ) If this does not look familiar to you: we give a gentle introduction to High Performance Computing along the way.

Undefined behavior (UB) is one of the features of C++ that is both loved and hated. Every C++ developer cares about performance, which is why it is very important to understand what the compiler can optimize and what are the language guarantees. Many times programmers are too optimistic about what the compiler can optimize, or they waste time optimizing code by hand. In this talk you will learn: - what is the “as-if” rule - why compilers know less than the programmer — the main problem with Translation Units - why compilers optimize based on UB, but don't warn about it - why Undefined Behavior can transcend time, removing your whole code without running 88mph - why having a more constrained language is better — optimizations that you can’t do in C