Blog

CppCon2016: All keynote/plenary sessions are now posted on YouTube

cppcon2016-plenaries.PNGCppCon 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.

CppCast Episode 71: CppCon 2016 with Chandler Carruth

Episode 71 of CppCast the only podcast for C++ developers by C++ developers. In this special CppCon episode Rob and Jason interview a group of Lightning Talk speakers and Chandler Carruth. Chandler discusses the topics of his two CppCon talks and using Modules at Google.

CppCast Episode 71: CppCon 2016 with Chandler Carruth

by Rob Irving and Jason Turner

About the interviewee:

Chandler Carruth leads the Clang team at Google, building better diagnostics, tools, and more. Previously, he worked on several pieces of Google’s distributed build system. He makes guest appearances helping to maintain a few core C++ libraries across Google’s codebase, and is active in the LLVM and Clang open source communities. He received his M.S. and B.S. in Computer Science from Wake Forest University, but disavows all knowledge of the contents of his Master’s thesis. He is regularly found drinking Cherry Coke Zero in the daytime and pontificating over a single malt scotch in the evening.

Chobo Single-Header Libraries Released

Chobo SHL is a collection of five small single-header libraries with no external dependencies by Chobolabs.

Chobo SHL Released

by Chobolabs

From the release:

The list of libraries is:

  • optional - A value wrapper with an optional invalid state (similar to boost::optional)
  • static_vector - A std::vector-like class with fixed capacity (similar to boost::static_vector)
  • flat_map - A std::map-like class with linear storage and optional storage container (similar to boost::flat_map)
  • vector_ptr - A non-owning std::vector pointer to be used in generic code
  • vector_view - A view of a std::vector<T> which makes it look as a vector of another type

doctest—the lightest feature rich C++ single header testing framework released!—Viktor Kirilov

The lightest feature--rich C++ single--header testing framework for unit tests and TDD

doctest 1.1.0 released!

by Viktor Kirilov

From the release:

The reddit thread might be of interest as well.

The project is looking for sponsors and publicity!

Video available: Grill the Committee—CppCon 2016

cppcon2016-grill.PNGCppCon is in full swing, and once again all the sessions, panels, and lightning talks are being professionally recorded and will be available online -- about a month after the conference, because it takes time to process over 100 talks!

However, the team is working around the clock to get the plenary sessions and the Monday evening Grill the Committee panel up as quickly as possible. Here is the Monday panel:

CppCon 2016: Grill the Committee Panel (YouTube)

Panelists: Hans Boehm, Chandler Carruth, Casey Carter, Marshall Clow, Richard Smith, Bjarne Stroustrup, Herb Sutter, Michael Wong

Summary of the talk:

What would you like to know about the C++ standard? Join us for a panel discussion with the leaders of the C++ standards committee where the audience asks the questions.

Concepts Lite vs enable_if—Andrzej Krzemieński

Why having concepts?

Concepts Lite vs enable_if

by Andrzej Krzemieński

From the article:

This post contains quite advanced material. I assume you are already familiar with Concepts Lite. For an overview of what Concepts Lite is, I recommend this proposal. Also, I have found this blog very useful regarding the details of and issues with concepts’ mechanics. One could look at Concepts Lite as three features:

  1. A superior alternative to enable_if (or overload hiding).
  2. The subsumption relation that enables the additional control of partial ordering in the overload resolution process.
  3. A convenient tool for building compile-time predicates that check for valid types and expressions.

In this post I will only focus on the first feature, and try to answer the question, “what do we need Concepts Lite for, given that we already have std::enable_if (and SFINAE)?”

Video available: Bjarne Stroustrup, “The Evolution of C++: Past, Present, and Future”—CppCon 2016

cppcon2016-stroustrup.PNGCppCon is in full swing, and once again all the sessions, panels, and lightning talks are being professionally recorded and will be available online -- about a month after the conference, because it takes time to process over 100 talks!

However, because of the importance of Bjarne's open keynote announcements on Monday, the team has pulled out the stops to process his video and get it up on YouTube (and maybe soon also Channel 9 for areas where YouTube is not available). It's there now, so if you couldn't be at CppCon on Monday in person, check it out:

The Evolution of C++: Past, Present, and Future (YouTube) (slides)

by Bjarne Stroustrup, CppCon 2016 opening keynote

Summary of the talk:

This is a philosophical talk. It deals with ideals, aims, and ways of approximating those. It deals with practical constraints and risks. It gives short examples. It presents a perspective of what drives the evolution of C++. What is C++ and what it must become over the next years for its success to continue? This involves both social and technical points. Towards the end, I discuss the direction of C++ future evolution, give some opinions, point to urgently needed new features, and discuss how to manage until they are part of the standard.