CppCon 2016: Garbage In, Garbage Out: Arguing about Undefined Behavior…—Chandler Carruth

Have you registered for CppCon 2017 in September? Don’t delay – Registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2016 for you to enjoy. Here is today’s feature:

Garbage In, Garbage Out: Arguing about Undefined Behavior...

by Chandler Carruth

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

There has been an overwhelming amount of tension in the programming world over the last year due to something that has become an expletive, a cursed and despised term, both obscene and profane: **undefined behavior**. All too often, this issue and the discussions surrounding it descend into unproductive territory without actually resolving anything.

In this talk, I'm going to try something very bold. I will try to utterly and completely do away with the use of the term "undefined behavior" in these discussions. And I will unquestionably fail. But in the process of failing, I will outline a framework for understanding the actual root issues that the software industry faces here, and try to give constructive and clear paths forward, both for programmers and the programming language.

And, with luck, I will avoid being joined on stage by any unruly nasal demons.

An Introduction to Reflection in C++—Jackie Kay

What's the status of reflection in C++?

An Introduction to Reflection in C++

by Jackie Kay

From the article:

Stop me if you’ve heard this one before. You are working on a messaging middleware, a game engine, a UI library, or any other large software project that has to deal with an ever-growing, ever-changing number of objects. These objects have many different qualities but can be grouped by their functionality: they can be sent across the network or collided with or rendered.

Because you are a good programmer who believes in the DRY principle, you want to write the “action” code that does the stuff on these objects without repetition, and plug in specific Message types or Renderable types into your generic pipeline at the appropriate places. It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to be able to automatically generate the rendering code for my widget based on the existing rendering logic for its constituent shapes...

Final Classes—Arne Mertz

Some thoughts about final classes.

Final Classes

by Arne Mertz

From the article:

A few days ago, a colleague asked me if it was wise to make every class a final class. Here is a more sophisticated answer than I could give at that time...

Post-Conditions on Self-Move—Eric Niebler

An issue we do not think often about:

Post-Conditions on Self-Move

by Eric Niebler

From the article:

TL;DR: In addition to the usual rule about move operations leaving the source object in a valid but unspecified state, we can add an additional guideline (not quite a rule, but follow it anyway):

Self-move assignment should “work” and leave the object in a valid but unspecified state.

Making things do stuff – Part 1—Glennan Carnie

C++ for embedded too!

Making things do stuff – Part 1

by Glennan Carnie

From the article:

C has long been the language of choice for smaller, microcontroller-based embedded systems; particularly for close-to-the-metal hardware manipulation.

C++ was originally conceived with a bias towards systems programming; performance and efficiency being key design highlights.  Traditionally, many of the advancements in compiler technology, optimisation, etc., had centred around generating code for PC-like platforms (Linux, Windows, etc).  In the last few years C++ compiler support for microcontroller targets has advanced dramatically, to the point where Modern C++ is a increasingly attractive language for embedded systems development...

Variadic CRTP—Steve Dewhurst

Steve Dewhurst has published a new paper under his category Once Weakly:

Variadic CRTP

by Steve Dewhurst

From article:

One problem with [the] traditional application of CRTP is that it’s inflexible....  We can get [more] flexibility by specifying the CRTP capability as a template template parameter.