C++Now 2021

A remarkable amount of progress has been made over the last 18 months towards the goal of bringing linear algebra to the standard C++ library. This talk will provide an update on those efforts, as well as provide some examples of how many of the proposed facilities could be used.

We'll begin with a very quick refresher on what linear algebra is, why it's so important in our modern world, and why linear algebra should be part of the standard library. Next, we'll summarize some important proposals that support the linear algebra effort and describe some of their capabilities and roles. Finally, we'll dive into several examples to see how these proposed facilities allows us to specify an interface that is intuitive, expressive, and supports fine-grained customization for those in search of higher performance.

Many years have passed since the release of C++11 and C++14. These standards brought many new features and idioms to the C++ language and revitalized its community. Nowadays, with C++20 having one foot out the door, it is important to look back at the experience gained using C++11/14 at scale and re-evaluate their impact. - What have we learned from 8 years of using Modern C++ in production at a large-scale corporation? - What features were the most useful? - Which ones were the most misused? From unexpected benefits/drawbacks to teachability issues, this talk will discuss the most significant consequences of embracing C++11 and C++14 in a company with thousands of engineers. With some *healthy* skepticism, commonly used features and idioms will be reassessed to uncover some unexpected pitfalls or qualities.

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.

Cling was the first interactive environment for C++. While it is an amazing piece of technology, it has several notable deficiencies, e.g. the loss of all previous work when a segfault occurs. In this talk, I discuss how modules can be used to perform incremental compilation in a fashion similar to what is available in Cling. The basic concept is that each cell of a notebook exports itself as a module which the following cell imports, forming a computational chain. The talk will consist of a demo on a notebook that is run from a Docker image. Interested participants will be able to download this image and experiment with the notebook.

Ranges have recently been introduced to the realm of C++ Standard. While the initiating idea was to increase the level of abstraction provided for the C++ Standard algorithms, it quickly evolved into a mechanism where users could code complex sequences of algorithms in an expressive and readable way. On the other hand, since C++17, when calling a C++ STL algorithm, the user is allowed to pass an execution policy as their first argument in order to control parallelization options. That enables the algorithm to run with vectorization optimizations or/and in parallel . It’s crucial to note though, that the execution policy option can only be used on the non-ranges overloads (namely, the iterator based ones), as ranges have been added in C++20 only. Therefore, the problem that emerges from the utilization of ranges, is the following: should the community push forward in order to embed the execution policy mechanism on the range based algorithms?
This talk is concentrated on providing insight on how the ranges could be parallelized and the possibilities that arise from such a powerful concept. Given that ranges are designed in order to support pipelining, trying to parallelize that kind of sequenties could potentially produce hundreds of subcases where algorithmic fusion would have to take place for every single combination. HPX, which is a C++ Standard Library for Concurrency and Parallelism, has taken serious steps in order to provide actual implementation proposals on how the machinery behind that could possibly work. The speaker provides the general algorithmic picture behind range parallelization, along with presenting tangible examples for candidate implementations.

In c++20 concepts have finally arrived. Despite long precedence for concepts via meta-programming in c++, concepts brings new facilities to the table. With implementations in compilers and standard library support we now need to step back and consider how to apply this new tool in real projects. How can we use standard library concepts for daily coding? How do we write concepts? How do we design libraries and frameworks with concepts?

This tutorial will climb up the concepts ladder: what's a concept, using concepts in code, reading concepts, writing concepts, and finally designing with concepts.  First we'll cover the basics of concepts, the concept and requires keywords. Then we'll explore the application of concepts from a library user point of view. Including as a variable declaration, return values, and function parameters. We look at Then we'll survey and apply c++20 standard library concepts to typical development of a typical c++ class.
Next the tutorial will dig into writing concepts. Taking a step by step approach we look at the details of concept definitions.  Refactoring std::sleep_for using concepts expand to types outside of std::chrono lets us zero in on concepts design alternatives for functions. And the creation of an interval concept provides an example of designing a library with multiple types using concepts.

Finally, we'll tie our new knowledge and look at some ways concepts can impact c++ designs.  We'll look back on what design is and the tools concepts bring.  How do concepts fit in with a multi-paradigm design world.  How do they compare to design principles like Liskov substitution that we currenlty use. Finally, we'll look at the serialization design pattern and see how concepts impact the tradeoffs involved.

The second 1/2 of a two part talk -- more focused on the writing of concepts and the design aspects.

In c++20 concepts have finally arrived. Despite long precedence for concepts via meta-programming in c++, concepts brings new facilities to the table. With implementations in compilers and standard library support we now need to step back and consider how to apply this new tool in real projects. How can we use standard library concepts for daily coding? How do we write concepts? How do we design libraries and frameworks with concepts?
This tutorial will climb up the concepts ladder: what's a concept, using concepts in code, reading concepts, writing concepts, and finally designing with concepts.  First we'll cover the basics of concepts, the concept and requires keywords. Then we'll explore the application of concepts from a library user point of view. Including as a variable declaration, return values, and function parameters. We look at Then we'll survey and apply c++20 standard library concepts to typical development of a typical c++ class.
Next the tutorial will dig into writing concepts. Taking a step by step approach we look at the details of concept definitions.  Refactoring std::sleep_for using concepts expand to types outside of std::chrono lets us zero in on concepts design alternatives for functions. And the creation of an interval concept provides an example of designing a library with multiple types using concepts.

Finally, we'll tie our new knowledge and look at some ways concepts can impact c++ designs.  We'll look back on what design is and the tools concepts bring.  How do concepts fit in with a multi-paradigm design world.  How do they compare to design principles like Liskov substitution that we currenlty use. Finally, we'll look at the serialization design pattern and see how concepts impact the tradeoffs involved.

Everyone uses dynamic memory in C++, but what is the performance cost that we are paying which we might be unaware of?

In this lecture we will talk about the performance aspects of using dynamic memory, more specifically:
* Allocating and deallocating memory: programs allocating and deallocating many objects can experience slowness because of memory allocation and deallocation.
* Memory access speed: sometimes, the bottleneck is related to how we arrange data in memory or the memory access pattern.

We will provide information on the reasons why the usage of dynamic memory is slow with examples and propose solutions or workaround to make it faster.

C++20 concepts give us a brand new way to specify how our generic libraries and algorithms should be used and allow library users to better understand what is expected of them. However, concepts didn't rise from chaos, and before their adoption C++ library authors had other mechanisms to meet that goal.

In this talk I'll briefly discuss concepts, describe a variety of more mature methods for libraries to constrain and tailor their interaction with application code. Mechanisms such as tag-dispatch, specializations and customization points will be compared to concepts and to each other, and usage tips will be presented.

Special attention will be given to the 'semantic' vs. 'syntactic' nature of concepts. I'll show potential pitfalls and 'famous' cases where semantics played a significant role, and present the case for some 'semantic only' concepts, and suggest how they can be used to improve library APIs.

The STL introduced an iterator abstraction into C++ that generalized the notion of pointer and allowed for the ability to have arbitrary sequences that could be generically traversed and have algorithms performed on them. But the C++ iterator-pair model isn't the only possible approach to solving this problem. The D Ranges model, while isomorphic to the C++ one, is still quite distinct and has some interesting characteristics. Many languages (including Rust and Python) have an entirely different iteration model from the C++/D one.

Are D Ranges better or worse than C++ Ranges? Is Rust's better than C++'s? Does it depend on what your definition of is is? The goal of this talk is to examine the problem space and find out.

This lecture is a continuation of my C++Now 2018 "Git, CMake, Conan: How to Ship and Reuse our C++ Projects" talk. This time I will share what I've learned and what has changed through the last three years in sharing and reusing C++ projects via CMake and Conan. I will share the updated best practices of packaging C++ projects and the most important highlights of the upcoming Conan 2.0.

If you are interested in package management in large enterprise projects, you probably do not want to miss this talk.

std::variant was added to C++ in 2017 as a type-safe alternative to C's union.
To start us off, I will shortly introduce the rationale of std::variant and the typical ways in which it can be used. I will also try to give insights into the way std::variant is typically implemented, highlighting the memory layout and its run-time performance implications.
The bulk of the talk will then focus on the key differences between std::variant and union, and discuss a common use-case where unions are typically used which std::variant does not support - serialization of streams of a trivially copyable object to files or to network. Then, I'll suggest approaches to tackle this shortcoming: Intrusive-Variant, Variant-of-Base. When presenting and describing the approaches above, I will dive deeper into what the C++ standard says about unions and their pitfalls, and discuss reasoning and issues. Time permitting, I'll finish off with a counterintuitive uses of std::variant - simple and safe mechanism for de-virtualization.
After attending this talk, participants should be better equipped to use this relatively new concept to modernize existing low-level C style code and will have a better understanding of how variants work under the hood.

It is tempting when writing function and class interfaces to use built-in or library types as function parameters and return values. "I want something to represent a count, I'll use an int", "I want something to represent a name, I'll use a std::string", etc. This works fine up to a point, but allows for confusion: if I pass two ints as the parameters to a std::vector<int> constructor, which is the size and which is the value? Is this float value for "timeout" a value in seconds or milliseconds?

One way to solve this issue is with use-specific classes: std::duration specifies time period with the units encoded, and many SI units libraries abound. However, writing such classes can be tedious and domain specific. To this end, many people advocate the idea of "strong typedefs": the ability to say "this type is like this other type, but is distinct from it", so I can have a "count" type that is essentially an "int", but is distinct from a "timeout_in_seconds" type that is also an int.

I will present the library approach I developed to address this problem, which uses templates to allow you to create specific types for specific purposes, with a set of "properties" that define the interface.

Testing in C++ is not easy, it often requires a lot of boilerplate code, macro usage and/or understanding of complicated testing frameworks.
But it doesn't have to be like that. C++20 will enable us to reinvent the way we write tests!

In this case study, we will address the difficulty of testing with C++ by implementing a new,
fully functional, macro-free testing framework [1] from scratch with modern C++20 features to make the following snippet compile and run:

01 import ut;
02
03 int main() {
04 "fib"_test = [] { // Running "fib"...
05 fib(7) == 12_i; // fib.cpp:5:FAILED [ 13 == 12 ]
06 }; // tests: 1 | 1 failed
07 } // asserts: 1 | 0 passed | 1 failed

At the end of this session, the audience will have a better understanding of C++20 features such as:

* Modules
* Concepts
* Source Location
* New additions to lambdas
* User-Defined Literals

Additionally, attendees will get familiar with an expressive way of testing with modern C++ based on UT - Unit Testing Framework [2].

Let's get ready to follow the Beyonce rule - 'If you liked it then you "should put a" test on it' and test all the things at C++Now 2021!

[1]: https://godbolt.org/z/a7Mses
[2]: https://github.com/boost-ext/ut

The constexpr metaprogramming model, which involves annotating code with indicators of compile-time or run-time suitability, has been steadily increasing in capabilities since its debut in C++11. These efforts have been in support of the stated goal of making metaprogramming accessible to even novice developers. Unfortunately, the result is a complicated and unintuitive programming model. Elsewhere, an extremely compelling alternative that is intuitive and more powerful has been implemented in Sean Baxter's circle compiler. This talk describes the limitations of the constexpr metaprogramming model and introduces its persuasive alternative, circle metaprogramming.

Crashed ! Now What ? “It works on my machine” :) Those little words that make the heart of QAs and clients skip a beat. Sometimes reproducing a crash on a developer's machine is next to impossible. Most of the time remote debugging is out of the question and all you’re left with are some scant log files and maybe a memory dump file, if you’re lucky. Wouldn’t you like to know the exact point of failure in the program and how it got there, on the client’s PC ?
How can you get your hands on a StackTrace of that crash on the client’s machine ? And how can you make any sense of it without symbols (client deployed Release build) ?
In this session, I’ll present a Windows specific technique we developed, that my team uses regularly to debug such scenarios in production. We leverage OS APIs like the Image Help Library (ImageHlp.dll), the Debug Help Library (DbgHelp.dll) to work with PE/COFF images and PDBs and reconstruct symbolicated StackTraces for Release crashes in production. The technique and APIs work all the way from Windows XP up to Windows 10, both for x86 and x64 executables.
We’ll see how symbols are loaded and how PDBs work, we’ll discuss partial/incremental PDBs and we’ll have to get comfortable with Structured Exception Handling (SEH). Did I mention Address Space Layout Randomization (ASLR) ? This is going to be fun :)
Come with me on this journey and we’ll walk the stack together, to reconstruct each frame, from a few pointers and some symbols.
From highly efficient platform-specific implementations, to boost::Stacktrace, to P0881, to C++23... we’ll analyze together the requirements, constraints and advantages of each design decision.