advanced

Quick Q: use of constexpr in header file

Quick A: const in a header implicitely means static.

Recently on SO:

use of constexpr in header file

constexpr implies const and const on global/namespace scope implies static (internal linkage), which means that every translation unit including this header gets its own copy of PI. The memory for that static is only going to be allocated if an address or reference to it is taken, and the address is going to be different in each translation unit.

That implied static for const variables was introduced specifically to use const instead of #define in header files in C++ to define constants. Without static there would be multiple symbol definitions linker error if that header file is included in more than one translation unit which were linked together.

In C++17 you can also make it inline, so that there is only ever a single copy of PI if an address or reference to it is taken (i.e. not static). inline variables were introduced in C++17 to allow for header-only libraries with non-const variable definitions in the header files.

In other words, you should use constexpr for your constants in header files, if possible, otherwise const. And if you require the address of that constant to be the same everywhere mark it as inline.

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

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