Declarative Functional APIs – A.K.A. Abusing Lambda Parameters—Philippe Groarke

Take some time to clear your thoughts before reading!

Declarative Functional APIs – A.K.A. Abusing Lambda Parameters

by Philippe Groarke

From the article:

Functional APIs are a joy to work with. Not only do they help eliminate certain bug categories, but they tend to be very flexible and reusable. Today I present a technique that has emerged while I was simplifying some lambda based APIs. C++17 makes template meta-programming much more palatable, I dare not imagine what this would look like in C++11...

Should Span Be Regular?—Barry Revzin

Do you have an opinion?

Should Span Be Regular?

by Barry Revzin

From the article:

In my last post, I talked about the concept of Westie types (yes, I am trying to make this happen), what Regular means, and which of them are Regular. I went through an explanation for why means for span is not Regular and potentially why it should be. After lots of resulting conversations with several people (thanks Zach Laine, Nicole Mazzuca, Eric Niebler, John Shaw, Tim Song), I thought it was necessary to write a follow up with more details and more argument...

Rvalues redefined—Andrzej Krzemieński

Evolution of semantics.

Rvalues redefined

by Andrzej Krzemieński

From the article:

In this post we will explore what I consider the most significant language change in C++17. I call it the most significant because it changes the way you design your resource-managing types and how you think about initialization. It is often called “guaranteed copy elision”, but I will not use that name (except for this single time) because it does not reflect what this feature is. C++ has completely changed the meaning of rvalue (actually, prvalue)...

How to Make SFINAE Pretty – Part 2: the Hidden Beauty of SFINAE—Jonathan Boccara

The next part.

How to Make SFINAE Pretty – Part 2: the Hidden Beauty of SFINAE

by Jonathan Boccara

From the article:

As we’ve seen in How to Make SFINAE Pretty – Part 1: What SFINAE Brings to Code, SFINAE in code is as pretty as a windmill in a field. That is, not very pretty.

But like a windmill, it’s useful. SFINAE helps deactivate a piece of template code depending on a condition, and that can be very convenient...

How to Make SFINAE Pretty – Part 1: What SFINAE Brings to Code

New series!

How to Make SFINAE Pretty – Part 1: What SFINAE Brings to Code

by Jonathan Boccara

From the article:

SFINAE is a bit like a windmill. It sits as a wart in the middle of an interface, BUT it’s useful to create elaborate static polymorphism, in particular before C++17 and if constexpr, and even in some use cases in C++17.

I thought we had to live with this tradeoff, until I watched a talk from Stephen Dewhurst at CppCon. In this inspring talk, Stephen shows how to turn SFINAE around to make it very expressive in an interface. Watching this talk changed my way of coding template interfaces...

Default-constructibility is overrated—Arthur O’Dwyer

What do you think?

Default-constructibility is overrated

by Arthur O’Dwyer

From the article:

The Ranges Technical Specification includes very many concept definitions (based on the Concepts TS), including for example Integral and Predicate. It also provides a concept named Regular which implements a variation on the “Regular” concept described by Alexander Stepanov in his paper '’Fundamentals of Generic Programming’’ (1998)...

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.)

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators—“No Bugs” Hare


‘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...

Without form and void—Barry Revzin

Did you encounter the problem?

Without form and void

by Barry Revzin

From the article:

In C++, void is a pretty strange thing. We can cast expressions to void, throw-expressions have void type, void* can point to anything, and void functions can actually return back to the caller. But we can’t have objects of type void or even write a type like void&. A function declaration like void f(void) is actually a nullary function. It’s a bit weird — but it’s not something a lot of people lose sleep over.

Until it starts wreaking havoc on your generic code — because it’s like the vector<bool> of the type system...