CppCast Episode 149: CppChat with Phil Nash

Episode 149 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Phil Nash to discuss the rebooted CppChat show, test driven development, a conference announcement and much more.

CppCast Episode 149: CppChat with Phil Nash

by Rob Irving and Jason Turner

About the interviewee:

Phil has spent the last year and a half doing things that might sound interesting for the next time he’s interviewed on CppCast. He might have overdone it. Aside from that he’s most commonly known as the original author of the test framework, Catch2. He’s been in or around C++ since the early 90s, but started coding in 1981 on a ZX-81 that he borrowed for six months. He’s worked in many domains, including finance and mobile and is now developer advocate for C++ and Swift tools at JetBrains.

Non-Ownership and Generic Programming and Regular types, oh my!==Barry Revzin

Do you know about it?

Non-Ownership and Generic Programming and Regular types, oh my!

by Barry Revzin

From the article:

This post is about a specific collection of types in the C++ core language and standard library. I am not sure of a good way to name this collection, and some terms that come to mind come with their own baggage, so I’m going to for now group them together under an umbrella that is clearly widely unrelated to programming and call them Westie types (because, like my dog, they are awesome yet enigmatic).

IO2D demo: CPULoad -- Michael Kazakov

A walkthrough of the CPULoad demo from the 2D Graphics proposal:

IO2D demo: CPULoad

by Michael Kazakov

From the article:

In my humble opinion, the 2D graphics proposal might bring C++ a solid foundation for visualization support. It’s powerful enough to build complex structures on top of it – here I can refer to the sample SVG renderer as an example. At the same time, it’s not built around some particular low-level graphics API (i.e OpenGL/DirectX/Mantle/Metal/Vulkan), which come and go over time (who remembers Glide?). What is also very important about the proposal is its implementability – I wrote the CoreGraphics backend in ~3 months on a part-time basis. It can be assumed that writing a theoretical Direct2D backend might take about the same time. While it’s easy to propose “just” a support for PostScript, SVG or even HMTL5, the practical implementability of such extensive standards is very doubtful. Having said that, I do think that the proposal, while being a valid direction, is far from being perfect and needs a lot of polishing.

Quick Q: Undefined behavior and sequence points

Quick A: No quick A.

Recently on SO:

Undefined behavior and sequence points

What are "sequence points"?

What is the relation between undefined behaviour and sequence points?

I often use funny and convoluted expressions like a[++i] = i;, to make myself feel better. Why should I stop using them?

If you've read this, be sure to visit the follow-up question Undefined behavior and sequence points reloaded.

(Note: This is meant to be an entry to Stack Overflow's C++ FAQ. If you want to critique the idea of providing an FAQ in this form, then the posting on meta that started all this would be the place to do that. Answers to that question are monitored in the C++ chatroom, where the FAQ idea started out in the first place, so your answer is very likely to get read by those who came up with the idea.)

Quick Update on C++ Compiler Bug Hunt--No Bugs" Hare

Looking for the bug.

Quick Update on C++ Compiler Bug Hunt

by No Bugs" Hare

From the article:

Some time ago, I wrote a post about kscope – mini-project on finding and reporting bugs in modern C++ compilers. The point was that there is a way to use C++ facilities to make C++ code self-mutating (more strictly – pseudo-randomized using externally supplied ITHARE_KSCOPE_SEED macro), which allows finding certain classes of bugs during randomized testing. In the previous post, I wrote about 12 bugs reported, with 3 of them already fixed. I have to admit that since that point, I didn’t have as much time as I’d like to spend on kscope; still, 3 more bugs were reported (2 of them being codegen bugs) – and quite a few were fixed (fortunately, bugfixing is one thing which doesn’t require my participation <wink />)...

Using C++17 std::optional--Bartlomiej Filipek

A reminder.

Using C++17 std::optional

by Bartlomiej Filipek

From the article:

Let’s take a pair of two types <YourType, bool> - what can you do with such composition?

In this article, I’ll describe std:optional - a new helper type added in C++17. It’s a wrapper for your type and a flag that indicates if the value is initialized or not. Let’s see where it can be useful and how you can use it.

std::iterator is deprecated: Why, What It Was, and What to Use Instead--Jonathan Boccara

You've been warned.

std::iterator is deprecated: Why, What It Was, and What to Use Instead

by Jonathan Boccara

From the article:

C++17 has deprecated a few components that had been in C++ since its beginning, and std::iterator is one of them.

If you don’t have C++17 in production, you’re like most people today. But one day or the other, your will have it, most likely. And when that day comes, you’ll be glad you anticipated the deprecation of such components, and stopped using them well in advance.

Let’s see how std::iterator was used, why it was deprecated, and what to use instead.

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators--"No Bugs" Hare

Actors.

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators

by "No Bugs" Hare

From the article:

As we briefly discussed in Part I of this mini-series [NoBugs17a], message-passing technologies such as (Re)Actors (a.k.a. Actors, Reactors, ad hoc FSMs, and event-driven programs) have numerous advantages – ranging from being debuggable (including post-factum production debugging), to providing better overall performance.

In [NoBugs17a] and [NoBugs17b], we discussed an approach to handling allocations for (Re)Actors, and then were able to achieve a safe dialect of C++ (that is, as long as we’re following a set of well-defined local rules). Now, let’s take a look at another task which can be facilitated by per-(Re)Actor allocators – specifically, at the task of serializing (Re)Actors that are later going to be de-serialized by the same executable. While one solution for this task was provided in [Ignatchenko-Ivanchykhin16], the proposed ‘ultra-fast’ serialization is rather cumbersome to maintain, and in most cases it can be beaten performance-wise by serializing at the allocator level...

Passing Booleans to an Interface in an Expressive Way--Jonathan Boccara

Readability is important.

Passing Booleans to an Interface in an Expressive Way

by Jonathan Boccara

From the article:

In order to allow a function to behave in several different way, and to allow its caller to choose amongst these behaviours, we have several tools at our disposal. Plenty, actually.

There are various sorts of polymorphisms embedded in the language such as virtual functions and templates. And we’ve also seen that a caller can specify the desired behaviour explicitly at call site. We’ve seen how to accomplish this by using tag dispatching, and also how to choose between enums and tag dispatching depending on your need.

I now want to top it off with a really simple technique, that will cost you almost nothing, but one that will make your code much more expressive. And even if it’s not rocket science I’m sharing this with you today because I’ve seen many a piece of code that could have benefited from it...