演讲与出版物

WebAssembly has become a very popular target platform for C++ developers. Thanks to emscripten, porting native applications to WebAssembly is easy — as long as the application only uses the browser as a display and input device. However, emscripten does not provide type-safe wrappers to the standard JavaScript APIs such as the DOM manipulation API, let alone any other JavaScript API provided by existing web applications. Our open source tool “typescripten” has been built on top of three powerful technologies to close this gap. It uses TypeScript interface definition files and the TypeScript compiler API to create type-safe C++ wrappers based on emscripten. TypeScript already has interface definition files for over 7000 JavaScript libraries that you can now use safely from C++. We strive to design our C++ wrappers such that the C++ code using them looks similar to the equivalent TypeScript or JavaScript code. However, the peculiar semantics of prototype-based Javascript and Typescript are often difficult to translate into a type-based language such as C++. I will discuss the challenges we faced and choices we made when designing this framework.

For twelve years, think-cell had been a Windows-only software company and our codebase of approximately 700k lines of code had accumulated many unintentional platform dependencies. Six years ago, we decided to port our application to the Mac. This change has affected every part of our development process: the project organization, build system and the way we program in C++ today. The commonly used cross-platform libraries such as Qt and boost were good tools to build on, but by themselves were not enough. For many concepts, such as mutexes, semaphores or shared memory, they only offer a common interface to platform-specific objects with very different semantics and lifetimes. We wanted light-weight, platform-independent C++ abstractions with identical semantics for rendering, internationalization, file I/O, mouse event handling, RPC calls and error reporting. Developing these was challenging, firstly, because we had to define which semantics our application needed and, secondly, we had to implement them on each platform. This was not an easy process but I would argue it has improved the quality of our code very much. By now, we have moved on to the next challenge and have started to move some functionality to web applications. We wanted to reuse our existing code-base of course, and that meant writing web applications in expressive, type-safe C++. Definitely an advantage in our book! We have built our web applications using emscripten, but we generate type-safe C++ bindings from any TypeScript interface definition. In my talk, I will give you an overview of the C++ abstractions we have implemented, focusing on the cross-platform problem areas where common semantics were hard to define due to limitations of either one of the operating systems, and of course I will show you our tools that let us write web application in C++.

Rvalue references have been with us since C++11. They have originally been introduced to make moving objects more efficient: the object an rvalue reference references is assumed to go out of scope soon and thus may have its resources scavenged without harm. The C++ standard library, for example, std::cref or std::ranges, makes use of yet another aspect of rvalue references: since they go out of scope soon, it is assumed unsafe to hold on to them beyond the scope of the current function, while lvalue references are considered safe. We, too, found this assumption to be very useful for smart memory management, particularly in generic code. Unfortunately, the C++ language itself violates this assumption in at least two places. First, rvalues bind to const&. This means that innocent-looking functions taking a parameter by const& and passing it through in some way silently convert rvalues to lvalue references, hiding any lifetime limitation of the rvalues. Std::min/max are two such examples. Worse still, every accessor member function returning a const& to a member suffers from this problem. Second, a temporary lifetime extension is meant to make binding a temporary to a reference safe by extending the lifetime of the temporary. But this only works as long as the temporary is still a prvalue. If the temporary has been passed through a function, even it has been correctly passed through by rvalue reference, lifetime extension will no longer be invoked and we get a dangling reference. These problems are not merely theoretical. We have had hard-to-find memory corruption in our code because of these problems. In this talk, Arno will describe the problems in detail, present a library-only approach to mitigate the problems, and finally, make an impossible-to-ever-get-into-the-standard proposal of how to put things right.

Ranges have been in the C++ standard for while now, and find their way into modern codebases. At think-cell, we have been developing and using our own range library for 20 years, which is built on top of the standard and is compatible with it, but goes beyond it in many aspects. Range adaptors are often stacked, a filter on top of a transform on top of etc. To make such a stack efficient, iterators are not good enough. We use a new concept that is more efficient and at the same time compatible with iterators so library users can keep using iterators as before. The standard library is very strict about the distinction between containers and views, and range adaptors are views which must maintain a reference to the data being adapted. Instead, we allow range adaptors to hold data themselves to make them self-contained and lazily evaluated at the same time. The standard iterator model only allows external iteration. However, internal iteration is often much easier to implement than external iteration. For many applications, internal iteration is completely adequate and more efficient than external iteration. Therefore, we bring internal iteration into the range family, to the point that the library user may not know or care which kind of iteration is being used. Standard algorithms return iterations and use the end iterator to signal some singleton state. By customizing return values, we can make our code more terse and expressive, for example eliminating these dreaded iterator end checks. These features combined make ranges an excellent tool for text formatting. We can use these ranges to represent the values to be formatted, conceptually turning them into lazily evaluated strings. These can be used just like regular strings are used today: in function returns; as standard algorithm input; embedded into other, equally lazily evaluated strings; and so on, before they are finally expanded for display. By choosing the right interfaces, we can optimize this expansion at compile-time, allowing both nice syntax and a performance which is very close to manually optimized code.

Text formatting has been a favorite problem of C++ library authors for a long time. In this talk, I want to convince you that the combination of ranges with a bit of metaprogramming makes for a very elegant solution to the text formatting problem. We introduce a form of ranges with internal iteration, which are generating their elements one by one rather than exposing external iterators. We can use these generator ranges to represent the values to be formatted, conceptually turning them into lazily evaluated strings. These can be used just like regular strings are used today: in function returns; as standard algorithm input; embedded into other, equally lazily evaluated strings; and so on, before they are finally expanded into a container. By choosing the right interfaces, we can optimize this expansion to the point that it is only 15% slower than creating the equivalent string using hand-optimized special-case code.

You understand iterators, right? How would you describe them? "Iterators are used to point into sequences of elements." Sounds good? More recently, the concept of ranges has been introduced to mean anything that exposes iterators. In particular, ranges include range adaptors for lazily transforming or filtering sequences of elements, and they, too, have iterators.
All good? Unfortunately, no. The iterator concept, which we have been using since the advent of C++, is fundamentally flawed. In particular, some iterators must behave differently depending on whether they are meant to point at an element or at a boundary between elements. So elements and boundaries are really two distinct concepts. In this talk, I will convince you that the problem is real and has practical implications, make a proposal on how to fix it and show how the solution not only fixes the problem but makes for clearer code and prevents mistakes.

Pairs of iterators are ubiquitous throughout the C++ library. It is generally accepted that combining such a pair into a single entity usually termed Range delivers more concise and readable code. Defining the precise semantics of such Range concept proves surprisingly tricky, however. Theoretical considerations conflict with practical ones. Some design goals are mutually incompatible altogether.

Every program may encounter errors, some originating from internal bugs in the program, others coming from the environment the program is operating in. Ignoring all errors will make the program utterly unreliable, while treating every conceivable one introduces lots of extra complexity with little benefit. At think-cell, we have been using and refining our own principled approach to error handling, which we have not seen elsewhere. This lecture teaches our method, so that you in your next project, too, can write more reliable software with less effort.

Rob Irving’s and Jason Turner’s CppCast of January 24th, 2018 interviewing Arno on the think-cell range library and C++ development at think-cell in general.

Office development is widely associated with boring VBA Macros, or hacky JavaScript. Many developers Valentin has talked to were surprised to learn that think-cell's code base has a million lines of C++ code, and that we had to create some generic libraries along the way to keep it that short. We strive to implement the most simple user interface on top of PowerPoint that enables users to create great-looking slides in little time, and for this we need to use very powerful tools. Let us show you how we apply state-of-the-art algorithms to solve layout and placement problems, and what challenges we had to overcome for seamless integration with the host application.

Software patching is a powerful but potentially risky method for fixing bugs, adding functionality, and improving the usability or performance of software. This lecture looks at patching software where the source code is unavailable, an activity commonly referred to as hacking. We discuss why and when such activity may be necessary before looking in detail at the design and implementation of robust patches. We finish off by describing various tools and techniques that can be used to find suitable patching locations.

We have recently begun to port our software to other platforms. In this process, we discovered the world of pain that are iostreams and C-style I/O. In this talk we give a short overview over why we have banished iostreams from our code base and what we have replaced them with.

The C++ memory model defines how multiple threads interact with memory and shared data, enabling developers to reason about concurrent code in a platform independent way. The talk explains multi-threaded executions and data races in C++, how concurrent code is affected by compiler and hardware optimizations, and how to avoid undefined behavior by using locks and atomic operations. Then it focuses on different memory orders for atomic operations, their guarantees and performance implications.

We love C++ and use it daily. In this talk we explain why – despite its reputation for complexity – C++ is conceptually a much better language than Java. Why? Because C++ knows value semantics. Because C++ has undefined behaviour. Because C++ does not enforce garbage collection. Because with C++ we can write code that is both abstract and efficient.

This paper presents an efficient algorithm for a new variation of the point feature labeling problem. The goal is to position the largest number of point labels such that they do not intersect each other or their points. First we present an algorithm using a greedy algorithm with limited lookahead. We then present an algorithm that iteratively regroups labels, calling the first algorithm on each group, thereby identifying a close to optimal labeling order. The presented algorithm is being used in a commercial product to label charts, and our evaluation shows that it produces results far superior to those of other labeling algorithms.

This paper presents a smart algorithm for labeling column charts and their derivatives. To efficiently solve the problem, we separate it into two sub-problems. We first present a geometric algorithm to solve the problem of finding a good labeling for the labels of a single column, given that some other columns have already been labeled. We then present a strategy for finding a good order in which columns should be labeled, which repeatedly uses the first algorithm for some limited lookahead. The presented algorithm is being used in a commercial product to label charts, and has shown in practice to produce satisfactory results.

In this paper we introduce a new algorithm for image and video texture synthesis. In our approach, patch regions from a sample image or video are transformed and copied to the output and then stitched together along optimal seams to generate a new (and typically larger) output. In contrast to other techniques, the size of the patch is not chosen a-priori, but instead a graph cut technique is used to determine the optimal patch region for any given offset between the input and output texture. Unlike dynamic programming, our graph cut technique for seam optimization is applicable in any dimension. We specifically explore it in 2D and 3D to perform video texture synthesis in addition to regular image synthesis.

In this paper we present a new approach for generating controlled animations of video sprites. Video sprites are animations created by rearranging recorded video frames of a moving object. With our technique, the user can specify animations using a flexible cost function, which is automatically optimized by repeated replacement of video sprite subsequences.