Partially-Formed Objects For Fun And Profit

On November, 3rd, we'll have the pleasure to welcome Marc Mutz to our user group. Marc is a senior software engineer with KDAB and author of the “Effective Qt” series of articles. He originated KDAB’s “In-depth Multithreading With Qt”, C++11 and C++17 courses, and runs “-Wmarc”, a blog about Qt, C++ and Boost. The second-most prolific contributor to QtBase and former maintainer of the QtWidgets module, he has actively used the framework for more than two decades, first as a KDE contributor, and then on the job. His most recent contributions to Qt are QStringView, an abstraction of string data from containers, QStringTokenizer, a lazy string splitter, and QAnyStringView, a variant string view type. Marc is a sought-after speaker at conferences on Qt and C++ topics and holds an MSc in Theoretical Physics.

---------------------------
Abstract: Lately, partially-formed states have gained some traction as the natural state of moved-from objects. Alexander Stepanov, in his landmark book Elements of Programming (EoP), defines them as a state in which the only valid operations are assignment and destruction. This state was, and continues to be, essential to high-performance code, and to the C++ guarantee of "don't pay for what you don't use".

After a brief introduction, we will look at where in the C/C++ language such states appeared even before there was a "C++", or the name "partially-formed", and certainly before the discussion about the moved-from state started. We thereby show that whatever you may think about the partially-formed state concept, it's there, as a Platonic Ideal in the world of computer programming. We will attempt nothing less than to carry the EoP treatment further into modern C++. In keeping with the spirit of EoP, there will be Propositions. We shall find that move semantics, as currently defined in the standard, are too strong, violating "don't pay for what you don't use", and give an overview of weaker alternatives, which are just as easy to learn and reason about, yet allow the most natural and efficient implementation of types that use them. A prime example will be flat_map.

We will also show how developers that feel uneasy about the partially-formed state can avoid them at little to no cost, neither in code readability, nor performance, and use these examples to propose a new (or old) paradigm for API design: safe and unsafe functions (in the Sean Parent sense).

---------------------------
Schedule:
19:00 (CET) -- Start of the videostream