The Meeting C++ online job fair returns!

by Jens Weller

The first two online events in remo have been a great success. They've been very well received by the C++ community and this event will now be a part of regularly scheduled events for Meeting C++ online. As remo is not available anymore, the event will be hosted in the new online event platform for Meeting C++ 2021. The event will be again on two days: 21st/22nd September, with the first day being in the afternoon and the second day in the evening...

A Multi-threaded, Transaction-Based Locking Strategy for Containers

by Bob Steagall

With the concurrency tools available in the modern C++ standard library, it is easier than ever to create multi-threaded 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 would like a locking algorithm that provides 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 approach to multi-threaded, transactional record locking that requires minimal spatial overhead and yet fulfils the requirements of atomicity, consistency, and isolation. We'll discuss the pros, cons, and limitations of the algorithm, and provide some performance measurements.

Time Travel: Applying Gradual Typing to Time Types with Clang's LibTooling

by Hyrum Wright

Libraries for C++ are constantly evolving, with new APIs being added, old ones being deprecated and functionality continually changing. In past CppCon talks, I've described in abstract how Google manages this change by applying large-scale changes across our C++ codebase using clang's libTooling infrastructure.

In this talk, we'll put this previous work in practice by demonstrating how we use clang-tidy and clang's libTooling library to improve type safety of time types across Google's 250M lines of C++. Using tools currently open sourced as part of clang-tidy, we'll show how the underlying model of time types allow us to migrate from a collection of integers and floating point types to the much more strongly typed `absl::Time` and `absl::Duration` types representing time instants and intervals. Along the way, we'll discover how this process finds existing bugs and prevents new ones from creeping in.

This "gradual typing" technique is not limited to just Time types, and we'll explore how this can be used to improve pointer ownership deduction and other places where more constraining types eliminate classes of bugs.

Back to Basics: Exceptions

by Klaus Iglberger

Exceptions are the native error propagation mechanism in C++. If used properly, exceptions enable us to write simpler, more readable and more robust code. However, the path there can be tricky and unfortunately the exception mechanism isn't without flaws. This talk sheds somelight on the current issues with exceptions and why a large part of the C++ community isn't using them. It also gives guidelines and best practices on how to deal with exceptions and how touse them properly. It will go into detail about the exception safety guarantees, explains the tradeoffs between them, and demonstrates by example the individual steps necessary to reach them.

Embrace Your Problem Domain With Strong Types!

by Richard Thomson

Every piece of software we write fits into some sort of specific problem domain. Programming isn't about writing programs! Programming is about solving problems. [...]

One area that is often overlooked when modeling our problem domain is coming up with abstractions for the most common and simple values used in our programs. "We need to store a telephone number for the customers in our inventory system." "OK, let's use a std::string, that ought to do it."

That's certainly an expedient solution, but is it a good solution? [...]

This month, Richard Thomson will give us a guided tour on how we can write domain specific types in C++. We'll take a look at facilities provided directly by the language to roll our own types and we'll look at some library solutions that save us from writing lots of boiler plate.

A Critical Look at the Coding Standards Landscape

by Michael Price

The C and C++ programming languages are rife with spiky pits, hairpin curves, and loaded footguns, leading industries working with critical systems to embrace strict standards that aim to reduce the amount of damage that can be done with the awesome powers available to them when using these languages.

This session will briefly review what sorts of standards exist in the public today, leading into a serious critique of the more foolish and user-unfriendly aspects of these standards, and finally closing with an optimistic view of “the good parts” of the same.

Dealing with Embedded Limitations

Panel Discussion hosted by Ben Saks

Many embedded systems have requirements on latency, memory usage, and resource consumption. This is especially true of safety-critical and security-related systems. Many programmers and organizations worry that using C++ features will prevent them from meeting these requirements. Some avoid using specific features such as exception handling, while others avoid using C++ entirely.

This panel will discuss the challenges and benefits of using C++ in embedded contexts. We will explore ways that embedded systems can leverage the power of Modern C++ features to meet their guarantees. We will discuss which concerns are based in fact and which concerns are based on misconceptions.
Feel free to bring your own questions about anything that you believe inhibits your use of modern C++ on an embedded system. We will discuss pre-selected questions as well as audience submissions.

Some Programming Myths Revisited

by Patrice Roy

We have been taught, or we ourselves have taught, things that we took for granted as being "good practice" in programming. Such things often stem from the "wisdom of the ancients" (although computer science being young as sciences come, some of the "ancients" are still among us and thriving today, and we're so lucky to have them!), and are in effect part of our "myths".

However, being as grounded in the science-that-there-was as these recommendations are, our ideas have evolved, so have our programming languages, and it can be interesting to revisit some of these taken-for-granted ideas.

In C++, particularly in what some call "modern C++", we find a language that is different enough from its forebears to make revisiting our "myths" interesting. How do such things as "goto considered harmful" or "only one return per function", for example, hold as "wisdom" with respect to modern C++? Do they still help us write better programs or should be rethink them under the light of modern languages and practice?

The aim of this talk is to examine what some commonly heard recommendations or advices with respect to programming practice mean in the context of "modern" C++. We will take a small set of such advices, present them in context, show how well (or how badly) they suit today's C++, and try to rephrase them if this seems advantageous.

The Surprising Costs of void() (and Other Not-Quite-Innocuous Evils)

by Patrice Roy

There are some things that might pass us by without us noticing them as evil or, as they have come to be known, Bad Code Smells.

Many of these little things are acceptable in some cases, and thus pass unnoticed in some code reviews. They are respectful of language rules, and thus pass unnoticed through the compiler's virtual hands. They might even lead to working code... and if it works, it's fine, no?

The idea for this talk came about when discussing with colleagues about such suspicious code and coding patterns, and hearing such questions as "but why is that a problem?". It's about those little evils that creep in code and poison our practice in subtle ways (making memory consumption higher than it should be, making execution slower than it should be, making reuse harder than it should be, etc.).

The Dawn of a New Error

by Phil Nash

As a community we've tried many different ways to express, propagate and handle error conditions in our code over the years. Each seem to have different trade-offs, with none being perfect in all cases.

This presentation is the follow-up to my earlier talk, "Option(al) Is Not a Failure", where I surveyed existing error-handling approaches and score them against each other, leading up to the new proposal, p0709, "Zero-overhead deterministic exceptions".

We'll summarise some of that background so we're all on the same page, but in this talk we're going to dig into the proposal in more depth - and look at the supporting proposals, p1028 (std::error) and p1029 ([[move relocates]]) and others. We'll also comment similar mechanisms in other languages, notably Swift, to get an idea of how it might work out in practice.