C++Now 2019

C++17 offers std::variant to model closed sum types and do pattern matching on them using std::visit (and eventually std::overloaded). While this is not as powerful as pattern matching in languages having this built in, it still allows to have a decent declarative design using mere library features.

It is also common to have this problem over an underlying open sum type, which can be modeled by means of inheritance and dynamic_cast or std::any, thus, relying on RTTI. This approach has two flaws compared to std::variant: firstly, dispatching using RTTI is much slower than std::variant and, secondly, C++ lacks a declarative counterpart for open sum types.

In this talk I will present solutions to both problems. I will show how a declarative dispatcher that works similarly to std::visit and the proposed std::overloaded can be implemented over open sum types. Further I will present an implementation that allows to model open sum types by inheritance but without relying on RTTI. By using both tools together a fast declarative pattern matching over type hierarchies can be built. The presented tools have been open sourced to 'matchine', a small library, and are already running in production code.

In the (more crazy) final part I will explore further possibilities of pattern matching as library feature. In particular I want to show some experiments of sorting the matching cases at compile time in order to do a binary search at run (match) time.

With the multithreading tools available in the modern C++ standard library, it is easier than ever to create multithreaded programs. When we write such applications, there are sometimes cases in which a container simply must be shared among multiple threads. Of course, sharing is trivial if the only operations on the container are reads. In the case where reads greatly outnumber writes, acceptable performance is often attainable with a reader/writer mutex type, like std::shared_mutex. But suppose that the number of writes is similar to, or even greater than, the number of reads -- how does one then perform simultaneous reads and writes on a single container?

One common usage pattern is that, for a given operation, sets of related records are read and updated together. In order to prevent data races and inconsistent views of the data, such sets must be locked together as a unit before any of them can actually be read or updated. Further, it is very easy to accidentally create deadlocks by choosing a seemingly correct locking order. In order to avoid these problems, we require that our locking algorithm provide three important properties: atomicity, consistency, and isolation.

This talk will describe an algorithm, implemented in C++, that performs such locking based on the concept of strict timestamp ordering. Using only facilities from the C++17 standard library, it employs a straightforward and novel approach to multi-threaded, transactional record locking that requires minimal spatial overhead and yet fulfills the requirements of atomicity, consistency, and isolation. We'll discuss the pros, cons, and limitations of the algorithm, and provide some measurements comparing the algorithm's performance to that of other techniques.

Over the years the term - Dependency Injection (DI) - has become more and more mystical while in actual fact DI is as simple as ABC. For those of you who have ever used constructors, you have inadvertently been using DI!

In this practical session, we will follow success stories of applying different forms of DI in several projects and focus on the outcomes as well as the potential pros and cons of using it.

We will establish why in an environment with constantly changing requirements [1] DI may play a crucial role if it comes to writing a maintainable/testable code with limited boilerplate and why "The only way to go fast is to go well".

The key point will be about comparing different ways [2], approaches [3] and frameworks [4] of accomplishing DI, each of which has different trade-offs, characteristics and which suits different applications.

At the end of this session, the audience will walk away with a clear understanding of possible use cases for DI, its benefits, as well as guidelines on how to correctly apply it.

Get ready to "inject all the things" at C++Now 2019!

[1]: "Nothing is certain in Software Development except for bugs and constantly changing requirements!" - the Franklin rule
[2]: Templates, Concepts, Type-Erasure, Inheritance, Variant - https://github.com/boost-experimental/di/tree/cpp14/example/polymorphism
[3]: Runtime/compile time injection - https://github.com/boost-experimental/di/tree/cpp14/benchmark
[4]: [Boost].DI - https://github.com/boost-experimental/di (not an official Boost library), Google.Fruit - https://github.com/google/fruit, Hyperdemic - https://github.com/ybainier/Hypodermic

Lightning talks are 5 minute talks on something of interest to C++ programmers. Presentation is open to any C++Now attendee, including Student/Volunteers.

Have a favorite technique or library to share? Employed some C++ feature in a project with amazing/horrible results? Want to start a conversation on Boost 3.0? Submit your proposal for a 5 or 10-minute talk to Michael at lightning@cppnow.org. Be sure to include a title, 3-sentence abstract, and something about yourself.

Come to be amused, enlightened, outraged, or inspired!

C++ 11 introduced move operations and thus made the old "Rule of Three" obsolete. While some just transformed that to become the "Rule of Five/Six" there is also a school of thought to propose "Rule of Zero". For beginners or pre-C++11 programmers this can be highly confusing.

Howard Hinnant gave a great presentation on the language rules which special members are defined or declared when, but we often lack the teachability on what to actually use.

Based on Howard's table and some categorization of class types, I suggest a consistent but may be surprising means to what special members to define or declare in what cases. Since I want to reduce of clutter there are some surprising suggestions. While unfamiliar today, I would like to make these suggestions more popular, so that we can get less code and thus more software.

In this case study, we will conduct a battle against different ways of implementing state machines in modern C++, each of which has different trade-offs and characteristics. We will use a connection [1] example to measure and compare varied aspects of each solution such as compilation time, run-time performance, memory usage, executable size, and readability.

In the first round, the Naive solutions will fight against Standard Template Library (STL) solutions. The Naive will be represented by the if/else and switch/enum, both of which could be classed as the 'old school' way of implementing state machines with implicit states defined by booleans and/or enums. On the other side, we will have STL, featured by C++17 - std::variant [2] and the newest addition to C++20 - coroutines [3]. These two can be used to demonstrate a new way of implementing state machines by leveraging modern C++ language features.

The winner will go on to take on the Boost libraries represented by Boost.Statechart [4] and Boost.MetaStateMachine (MSM) [5]. Both libraries are compliant with Unified Modeling Language (UML) standard [6] and have many additional features such as logging and/or serialization. Whilst Statechart is more run-time, the MSM represents a fully compile-time approach with minimal run-time overhead.

While our winners are recovering, we will introduce the final contender - [Boost].StateMachineLanguage (SML) library [7] - a C++14 version of Boost.MSM of which I'm the author and claimes to have much faster compilation times then its precursor. We will follow by some 'godbolting' (comparing a generated assembly) [8] of different dispatching techniques (branch, switch, jump table, fold expressions [9]) available in the library to illustrate the main power of the SML - the ability to change the feature set and behavior at compile-time.

After that, we will return to the final round, where the winner will battle against [Boost].SML.

At the end of this epic battle, the audience will walk out with a clear understanding of possible state machine implementations, their trade-offs, and with guidelines of what solutions suit what problems.

Let's get ready to rumble at C++Now 2019!

[1]: http://boost-experimental.github.io/sml/embo-2018/images/connection.png
[2]: http://en.cppreference.com/w/cpp/utility/variant
[3]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4736.pdf
[4]: http://www.boost.org/doc/libs/release/doc/html/boost_statechart.html
[5]: http://www.boost.org/doc/libs/release/doc/html/boost_msm.html
[6]: https://www.omg.org/spec/UML/2.5.1/PDF
[7]: https://github.com/boost-experimental/sml(Boost.SML is not an official Boost library)
[8]: https://godbolt.org/g/HVavPU
[9]: http://en.cppreference.com/w/cpp/language/fold

The C++20 Standard Library - Beyond Ranges

C++20 has a large number of new library features. This survey course provides students with a broad overview of the changes and new facilities in the C++20 standard library. Ranges are briefly discussed, but the focus is on the myriad of other standard library changes targeted at C++20. These include expanded chrono support, concepts library, string output formatting, span, flat_map, contains on associative containers, heterogeneous lookup on associative containers, uniform container erasure, u8string and u8string_view, bit manipulation facilities, functions and types to support relational comparisons, sync_buf and osync_stream, and threading primitives such as atomic_ref.

The tutorial will be up to date with the latest working draft following the Kona meeting and will include pointers to current implementations as well as the state of compiler support.

Chock full of example codes, this tutorial will focus on practical application of the new c++20 standard library facilities.

(90 minutes)

Video, Slides.

* What the C++Now and CppCon are. Brief history, purpose, and difference.
* How to attend CppCon and get money for that.
* How to attend C++Now and CppCon for free or partially for free.
* How to avoid the expenses for the conference ticket, hotel, flight, pre-conf- and post-conf-classes.
* How certain parts of the conferences work. Roles, tools, how one can participate and what it gives.
* Future of C++Now and CppCon.
* Annual time line of CppCon and C++Now. When to do what.

Bonus Topics:
* How speakers can make their talk(s) available not only in the talk's language but in other languages also, and thus to become more visible around the world.
* In which companies one needs to work to be sent to C++Now and CppCon.
* What one needs to do to be sent to the conferences.
* What the employers might want to know before sending their employees to the conferences.

There has been an expansion on the number of tools that perform static analysis and automated refactoring, following the development of clang and, more importantly, clang's tooling library. The talk will go over background on the development of the area, explain how Bloomberg is using clang tooling to advance its automated refactoring needs, and also do a case study of the development process of a tool at Bloomberg.

We will also cover clangmetatool[1], which is the open source framework we use when producing clang tools, and walk over the entire life cycle of how a automated refactoring tool is implemented, how we manage the execution of that pipeline to completion.

[1] https://bloomberg.github.io/clangmetatool

This presentation will explain and review Parametric Expressions (P1221), a proposed language feature for C++. Parametric Expressions are a hygienic macro on expressions that occur during semantic analysis and template instantiation. Simply put, they are functions without an actual function call or type. This allows working with intermediate "placeholder expressions" such as overloaded functions and parameter packs resulting in more concise interfaces that hide scary template code, while also providing a means for lazy evaluation. Because it lacks overloading, function type instantiation, type deduction, SFINAE, and all of the other features that function templates provide, it can make build times considerably faster especially when the type names are bloated.

First, there will be an entry level expository for those who have no idea what Parametric Expressions are along with simple, motivating use cases. Then we will gradually work our way up to more complicated uses that would benefit library authors involving techniques such as mixing compile-time with run-time computations.

Audience participation and discussion is highly encouraged.

Lightning talks are 5 minute talks on something of interest to C++ programmers. Presentation is open to any C++Now attendee, including Student/Volunteers.

Have a favorite technique or library to share? Employed some C++ feature in a project with amazing/horrible results? Want to start a conversation on Boost 3.0? Submit your proposal for a 5 or 10-minute talk to Michael at lightning@cppnow.org. Be sure to include a title, 3-sentence abstract, and something about yourself.

Come to be amused, enlightened, outraged, or inspired!

Library in a week work session.

At C++Now 2018, Arthur presented three candidates for "The Best Type Trait C++ Doesn't Have." One of these candidates was `is_trivially_relocatable＜T＞`, as seen in popular third-party libraries such as Folly, BSL, and EASTL. In the past twelve months, Arthur has implemented `__is_trivially_relocatable(T)` in a branch of Clang, made it available on Godbolt Compiler Explorer, and written it up in a proposal targeting the C++2b standard — P1144 "Object relocation in terms of move plus destroy."

In this talk, we'll explain again what "relocation" is and why it's important. (It's the operation consisting of a move-construction and a destruction which is the backbone of vector reallocation, type-erased move-construction, and swap.) We'll explain five common library optimizations that are today applied conservatively only to "trivially copyable" types such as `int*`, and show that they can be applied just as well to "trivially relocatable" types such as `unique_ptr＜int＞`. Time permitting, we may show benchmarks similar to last year's 3x speedup on `vector::resize`.

Most importantly, Arthur will list several things that P1144 object relocation is NOT, and explain each of them briefly, with examples. P1144 object relocation is NOT N4158 "Destructive Move" (Pablo Halpern, 2014): We'll briefly explain N4158's mechanism and its rejection by the Committee, then show how P1144 addresses those problems. P1144 object relocation is NOT data-structure-level "position-independence" or "persistability": Arthur will explain why he believes P1144 doesn't get C++ any closer to foolproof position-independent data structures. P1144 "trivially relocatable" is NOT Itanium's "trivial for purposes of ABI" attribute: Arthur will explain why they're orthogonal.

Finally, we'll discuss open design issues. There are three reasonable syntax proposals, currently named [[trivially_relocatable]], [[maybe_trivially_relocatable]], and [[trivially_relocatable(bool)]]; we'll compare examples of library code using each of these syntaxes. We'll ask what we ought to require of a trivially relocatable type's copy constructor and assignment operators. And we'll relate P1144's object-lifetime issues to P0593 "Implicit creation of objects for low-level object manipulation."

Data structure intuition is something that develops naturally for most software developers. In all languages, we rely heavily on standard containers and collections. Need fast insertion/lookup? Hashmap. Need a sorted data structure that stores unique values? Set. Duplicate values? Multiset. And so on.

However, most software developers don't develop algorithm intuition quite as easily. Algorithms aren't taught as widely as data structures are, and aren't relied on as heavily. This talk aims to introduce some STL algorithms, show how they are commonly used, and show how by developing intuition about them (+ a little help from lambdas), you can unlock their true potential.

Composition is the essence of code architecture, and monoids are a powerful and
underappreciated compositional pattern that is lurking in code of all kinds.
Identifying and exploiting monoids is perhaps the best way to improve our code's
large-scale architecture, in the same way that recognizing algorithms and
replacing raw loops is a great way to improve small-scale architecture.

When we start looking for monoids, we find that they are everywhere, and it's
not just about std::accumulate with addition! In this talk I want to develop an
intuition for recognizing this ubiquitous design pattern. I will show some ways
to think about code capabilities at a higher level, and how thinking in terms of
monoids can help us with things like API design, incremental computation,
evolving system state and distributing work. Along the way we'll also look at
how C++ language and library features can support putting monoids to work in our
code.

Implementing the C++ standard library is both similar to writing a boost library and yet quite different. In this talk, I'll lead off with what are some of the challenges that a standard library implementor faces, as well as the advantages that one has.

Then, I'll apply the principles to the task of maintaining/improving a boost library, and note where the similarities and differences lie. Many of the motivations (stability, portability, etc) are almost exactly the same.

I'll also talk about balancing the needs of different "customers"; people who use the standard library in different ways, and what you can do to keep all (most?) of them happy.

The planning committee for next year's conference gets started early. Join us if you'd like provide suggestions or otherwise pitch in.

Library in a week work session.

There was (and still is) much controversy around the discriminated union variant type included in C++17. This talk is a first hand account of the process as well as the details of the various design deliberations and tradeoffs that were made to achieve consensus. It will get into both the performance and usability considerations that were debated, as well as some speculation as to where the C++ committee might like to take it in the future.

For years, the callback paradigm with a function pointer and sometimes a void pointer to some user data has dominated synchronous (and sometimes asynchronous) programming extension models in C. Yet later still, C++ code virtual classes, override-able (pure) functions have been used (and abused) with varying degrees of success in projects that seek to extend their functionality beyond what was originally programmed. Unfortunately, virtual classes are still too heavy for many cases where external-to-application extension was not really necessary, leaving developers to add various sorts of hooks and serialization which are increasingly being milled through templates and other extension points.

Is there something better than the typical callback paradigm or virtual class methods for allowing a user to hook a library or middleware's inner workings?

This case study will review several libraries and discuss the merits of their non-dynamic extension points, including virtual serialization in game engines, iostream higher order function mechanisms, sol3 and nlohmann::json. We will discuss the pros and cons of each, how extensible they end up being, and what limitations come from choices such as ADL extension (with and without priority tags) or struct template specialization. Come join us for a deep dive in what it means to allow a developer to extend your application with their types and routines at compile-time!

The people who bring you Boost and C++ Now! talk and answer questions about what they see coming.