CppCon just concluded on Friday, and all five keynote/plenary sessions are now posted. Again, all the sessions, panels, and lightning talks have been professionally recorded and will be available online -- but it takes time to process over 100 talks, so expect it to take a few weeks to get them all up.

We already linked to Stroustrup's opening keynote and the Grill the Committee Panel. Here are the links to the rest of the keynote/plenary sessions -- you won't want to miss them.

extern "C": Talking to C Programmers About C++ (Dan Saks)

Our summary: A wonderful talk on communication skills and efficiency facts vs. perceptions, while staying well grounded in technical substance and empirical measurement throughout.

Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17 (Jason Turner)

Our summary: A tour de force on what "zero overhead" really means, and how and why C++ delivers it, with live demonstration of "what this code actually compiles down to" throughout. You'll be linking to this video for a long time when someone asks whether C++ really compiles to clean-and-lean object code.

Developing Blockchain Software (David Schwartz)

Our summary: One of the world's leading experts in an economically important software field shows what "demanding software" entails and how C++ works well to meet the efficiency and security challenges of Bitcoin and Ripple.

Leak-Freedom in C++... By Default (Herb Sutter)

Our summary: A "Part 2" of last year's talk about preventing dangling "non-owner" pointers and iterators, this year's talk deals with the complementary topic of how to manage "owner" abstractions so that unused objects are cleaned up promptly, without resorting to "delete" and dealing with real issues like bounded stacks and cycles.

Here are the longer abstracts below. We hope you enjoy the talks.

extern "C": Talking to C Programmers About C++ (Dan Saks)

Most of us have heard this story. We’ve even told it ourselves…

C++ is nearly all of C, plus a whole lot more. Migrating code from C to C++ is pretty easy. Moreover, the migration itself can yield immediate benefits by exposing questionable type conversions that can be sources of latent bugs. After migration, the code performs as well in C++ as in the original C. And now that it’s C++, you have ready access to a wealth of advanced features you can (but don’t have to) use to implement enhancements.

Who wouldn’t want that? Legions of C programmers, apparently.

Despite the success of C++ in numerous application domains, C remains considerably more popular, especially in embedded, automotive, and aerospace applications. In many cases, projects resist C++ because their managers think the risks outweigh the benefits. In other cases, the resistance comes from programmers who persist in believing bad things about C++, even when those things aren’t true.

What can the C++ community do to overcome this resistance? Drawing on lessons from cognitive science, linguistics and psychology, and (of course) computer science, this talk offers suggestions about how to make the case for C++ more persuasive to C programmers.

Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17 (Jason Turner)

The Commodore 64 was released in 1982 and is the best selling computer model of all time. At 34 years old, even the most simple embedded processor today outperforms it. Join me on an exploration of how C++17 techniques can be utilized to write expressive, high performance, high level code for simple computers. Together we will create a game for this aging system.

You'll leave the talk with a better understanding of what your compiler is capable of and be able to apply these ideas to create better code on modern systems.

Developing Blockchain Software (David Schwartz)

This talk will explain what public blockchain systems like Bitcoin and Ripple are, the unique challenges of developing software for them, and how C++ helps to meet these challenges.

Security issues are paramount. Blockchain systems are open source, have large attack surfaces, and can cause significant financial damage if they have exploitable defects. Performance and scalability are also major concerns.

C++ provides a unique balance that helps meet these challenges. The language's design makes it possible to catch bugs at compile time, write modular code that can be tested, develop flexible data structures and manage resources. Yet, where performance is critical, it does not obscure what your code is making the computer actually do.

The primary purpose of the talk is to explain what blockchains are, increase understanding of the unusual challenges developers of blockchain software experience, and to demonstrate why C++ is a good choice to address them.

Leak-Freedom in C++... By Default (Herb Sutter)

Lifetime safety means writing code that, by construction, is guaranteed to eliminate two things: (a) use of null/dangling pointers (including pointerlike things such as references, iterators, views, and ranges), and (b) leaks (including the rare 1% case where we’re tempted to admit the possibility of an ownership cycle or need to support lock-free concurrent data structures).

Last year, my CppCon 2015 talk “Writing Good C++14… By Default” focused on (a), null/dangling, because it's the more difficult and usually more serious problem. I gave an overview of a new approach of using static analysis rules to eliminate use of null and dangling in C++. That work continues and we’re in the process of writing down the formal rules for the approach that I showed last year.

This year, the focus will be on (b), leaks: The talk aims to begin with a set of simple rules, the “5-minute talk” to demonstrate that a handful of rules can be taught broadly to programmers of all levels, and results in code that is clean and free of leak bugs by construction.

But, since we’ll still have 85 minutes left, we can use the time to spelunk through a series of “Appendix” code examples, in which we'll demonstrate "why and how" to apply those rules to a series of increasingly complex/difficult situations, and that are aimed at increasingly advanced and “clever” (note: not always a good thing) programs and programmers. We’ll address questions such as: How should we represent Pimpl types? How should we represent trees – what should the child and parent pointer types be, and (when) should they be unique and when shared? How should we deal with “intra-module” or “encapsulated” cycles when you control all the objects in the cycle, such as all the nodes within a Graph? And what about “inter-module” or “compositional” cycles when you don’t know in advance about all the objects that could be in the cycle, such as when combining libraries written by different people in a way that may or may not respect proper layering (notoriously, using callbacks can violate layering)? The answers focus on cases where we have solid guidance, and then move toward some more experimental approaches for potentially addressing the ~1% of cases that aren’t yet well covered by unique_ptr, shared_ptr, and weak_ptr.