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.

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