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.

Test Driven C++

by Phil Nash

We know that testing is important, but writing tests is hard and takes time - and can be demotivating when you want to hack out features.

But what if we flipped the whole thing around? It turns out that by writing tests _first_ the dynamic changes in unexpected ways. Testing becomes easier. Adding features becomes easier. The dopamine hit you get from seeing something work becomes more frequent. Time lost to bugs and regressions virtually disappears. You start to get invited to bigger and better parties!

Ok, one of those statements is not guaranteed - but the rest are! If you've never tried TDD (perhaps you have heard of it but been skeptical), or maybe had a bad experience in the past, this talk will give you a sound intro to how it work, how you can get started, and what you can expect to achieve.

Shift-M/47: Bjarne Stroustrup on the future of programming

by Yegor Bugayenko

00:00 Introduction
00:58 How to make a language popular
06:24 Do we need committees to add new features to the language
13:05 Future of C++
14:54 NoCode
17:51 AI for optimizing of source code
23:28 Formal definition of language
28:05 Complexity of languages
41:18 Mistakes in C++
46:37 Future of programming languages
48:39 What was the purpose of creating C ++
56:59 Life goal

From Algorithm to Generic, Parallel Code

by Dietmar Kuhl

This presentation starts with a parallel algorithm as it is described in books and turns it into a generic implementation. Multiple options for running the algorithm concurrently based on different technologies (OpenMP, Threading Building Blocks, C++ standard-only) are explored.

Using parallel algorithms seems like an obvious way to improve the performance of operations. However, to utilize more processsing power often requires additional work to be done and depending on available resources and the size of the problem the parallel version may actually take longer than a sequential version. Looking at the actual implementation for an algorithm should clarify some of the tradeoffs.

Showing how a parallel algorithm can be implemented should also demonstrate how such an algorithm can be done when there is no suitable implementation available from the [standard C++] library. As the implementation of a parallel algorithms isn't trivial it should also become clear that using a readily available implementation is much preferable.

Practical Memory Pool Based Allocators For Modern C++

by Misha Shalem

Runtime-deterministic memory allocations are a crucial aspect of any safety-critical real-time system. One of the simplest and widely adopted allocation mechanisms used in such systems is a memory pool with fixed block sizes. Unfortunately, the need to know the exact sizes of the memory blocks makes any practical usage of memory pools with standard C++ allocator-based approach rather problematic since users often “hide” real properties of allocations which are made under the hood. For example: STL’s node-based containers like 'std::map' as well as other standard mechanisms like 'std::promise' or 'std::allocate_shared'.

Being a company which focuses on real-time safety-critical applications, we still see a significant value in keeping compatibility with the standard allocator model as well as in following common conventions which are familiar to every C++ developer.

This talk presents an approach which uses a combination of a memory allocator implementation which instruments the code, and an external LLVM-based tool which extracts the instrumentation information and generates static memory pool definitions, allowing the allocator to switch from the heap to a memory pool without any further changes to the code. The presentation will walk through a simplest possible implementation of this approach.

How to Herd 1,000 Libraries

by Robert Schumacher

In the current C++ world, it is a struggle to convince even a single external library to build and behave. Adding a third and fourth dependency causes quadratic grief as each library interacts with each other and One Definition Rule violations lurk around every corner.

How, then, is it possible to manage over 1,000?

In this talk, we'll talk about the techniques, shims, and hacks used in the Vcpkg package manager to persuade, connive, and coerce all these independent moving parts into a single robust ecosystem. We'll sample the myriad approaches used by real-world libraries to declare dependence and walk through how they can be guided to do the right thing at the end of the day.

Private package management systems still thrive in corporations and these approaches can provide method to the madness of consuming open source.