advanced

CppCon 2016: C++14 Reflections Without Macros, Markup nor External Tooling..--Antony Polukhin

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:

C++14 Reflections Without Macros, Markup nor External Tooling..

by Antony Polukhin

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

C++ was lacking the reflections feature for a long time. But a new metaprogramming trick was discovered recently: we can get some information about POD structure by probing it's braced initializes. Combining that trick with variadic templates, constexpr functions, implicit conversion operators, SFINAE, decltype and integral constants we can count structure's fields and even deduce type of each field.

Now the best part: everything works without any additional markup nor macros typically needed to implement reflections in C++.

In this talk I'll explain most of the tricks in detail, starting from a very basic implementation that is only capable of detecting fields count and ending up with a fully functional prototype capable of dealing with nested PODs, const/volatile qualified pointers, pointers-to-pointers and enum members. Highly useful use-cases will be shown a the end of the talk. You may start experimenting right now using the implementation at https://github.com/apolukhin/magic_get.

Making things do stuff – Part 6--Glennan Carnie

The series continues.

Making things do stuff – Part 6

by Glennan Carnie

From the article:

As code designers we tend to eschew specific ‘stove-pipe’ code in favour of reusable code elements.  Up until now we’ve been coding some very specific examples so it’s probably worth looking at some more generic solutions.

In this article we’ll look at building generic register manipulation classes (or, as one commenter referred to them, ‘register proxy’ classes).  Here, we’re really exploring code design rather than coding ‘mechanics’.  I’m using this to explore some factors like the balance between efficiency, performance and flexibility...

Making things do stuff – Part 5--Glennan Carnie

The series continues.

Making things do stuff – Part 5

by Glennan Carnie

From the article:

We’ve been looking at using C++ to manipulate I/O hardware.   Previously, we’ve looked at the fundamentals of hardware manipulation; and how to encapsulate these mechanisms into classes.  If you’ve not been following along I’d recommend reading the previous articles first before continuing.

This time we’ll explore a lesser-known feature of C++ and its application in hardware manipulation – placement new...

Making things do stuff – Part 4--Glennan Carnie

The series continues.

Making things do stuff – Part 4

by Glennan Carnie

From the article:

In the last article we explored the design of a class to encapsulate a physical hardware device.  In that article I deliberately ignored how the class would actually interact with the hardware.

In this article we explore the options available to us for accessing hardware and the consequences of those choices...

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.