CppCon 2018

After introducing uniform initialization with C++11, there are at least 5 ways in C++ to initialize an object.
Each have them has different rules, different effects, and different usage depending on the context and goals.
The situation is so confusing that today nobody can tell anymore which type of initialization to teach to beginners.
That's nothing but a disaster.

This talk will discuss the different forms of initialization, compare them to know when to use which, discuss what changed with C++14 and C++17 and what still has to change, and finally what to teach now to beginners.
I promise a source of trouble and discussion.

One of the main defining features of C++ is that of well defined object lifetime. We know that when a scope exits any local variables will be properly cleaned up. This is something that we rely upon and use regularly for the management of resources (ie RAII).

However, there are some corners of the language that challenge our understanding of object lifetime. I have been teaching classes on understanding object lifetime for over a year now and some of these places continue to surprise my students and have even surprised me.

We will explore these corners of C++ and ask if they cause enough concern that the language features should not be used, or if they are still worth the price? We will also ponder if these can be considered mistakes in the language or just side effects of a useful feature. We will also explore when and how the compiler and analyzers can warn on these issues.

C++ major benefit is its deterministic lifetime model of variables and values. This lead to the RAII (resource-acquisition is initialization) idiom that is essential for resource safety and less leakage. Some standard library classes already implement RAII for specific cases, such as heap-allocated pointers, mutex locking or file-I/O.

While some "mis"-uses of unique_ptr are recommended as a general RAII wrapper, those uses sometimes fail to be general enough. This lead Andrew Sandoval to specify a unique resource wrapper for the standard libary in 2013 (N3677). This talk tells the story how the author helped shepherding that mechanism through at least 12 revisions to make it into the standard library, which might be achieved while CPPCon runs, or not yet (hopes are high).

Implementing a RAII wrapper seems trivial, just implement a constructor and destructor, but doing so in generic ways is hard and tricky. Even with simple DIY solutions, interesting effects lurk and can lead to surprises also when using the generic solutions potentially provided by C++20.

Join Arthur O'Dwyer on a deep dive into Return Value Optimization and related topics.

Even C++03 allowed the compiler to "elide" copy construction in certain cases. We'll start with an explanation of the calling convention on a typical machine, showing where the mysterious "return slot" lives, and why it makes sense that C++03 allowed copy elision in certain special cases (but not others). Then we'll show how C++11 (and a subsequent defect report) upped the game by quietly turning the remaining copies into moves, so that the commonly received wisdom these days is that `return std::move(x)` is never necessary and often a pessimization.

...Or is it? We'll show some real-world examples where `return x` quietly copies a large object instead of moving it. We'll explain the little-known notion of a "converting constructor", contrast it with "conversion operator", and show the precise way in which C++17 drops the ball on these examples. Finally, Arthur implemented a Clang compiler warning to detect and suggest fixes for problematic return statements; he'll walk through the relatively painless process of creating that diagnostic, and perhaps inspire you to contribute to Clang yourself!

It's easy to create an access a global object in C++, but doing so correctly and safely is unfortunately a bit tricky. But why?

This talk will take a close look at the various rules that govern when an object is safe to access, including storage duration, object lifetime, initialization, and program termination. We'll look at some safe idioms for creating global singletons that are justified by these rules. And we'll look at the relevant, helpful features added in various revisions of C++, such as constexpr constructors, and how they make the situation better.