# README for my Peaceful Encampments visualizer

In a series of previous blog posts, I showed a lot of pretty pictures for the “Peaceful Encampments” problem:

# What is Type Erasure?

I love type erasure in C++. But I find every so often I’ll be in a conversation with someone, and they’ll use the phrase, and they won’t mean quite the same thing as I mean, and it’ll take a while before we realize that we’re talking about completely different ideas. So I think it’ll be useful to write down what I mean by the phrase “type erasure” in C++.

# RFM: Request for mashups

I offer the following concepts to the world in the hope that the world will make them happen. …

# Value category is not lifetime

Here’s another slogan that needs more currency:

Value category is not lifetime. …

# Four versions of Eric’s Famous Pythagorean Triples Code

Back in December, Eric Niebler made some waves in the C++ twitterverse with a post titled “Standard Ranges” (2018-12-05). …

# Thoughts on P1306 “Expansion Statements”

Daveed Vandevoorde’s P1306R1 “Expansion Statements” proposes three interesting extensions to the language: for... (auto arg : pack) and for... (constexpr int i : array) and for... (auto arg : tuple). I was in EWG in Kona when this paper was presented, and observed that the proposed syntax is slightly messed up by the way it conflates two of these three distinct cases. But upon reflection, I’m not sure it’s possible to solve the third case without some conflation anyway.

# Is __int128 integral? A survey

How well is __int128 supported, and what are its properties? A Godbolt-based survey of the Big Four compilers. Spoiler alert: libc++ thinks it’s integral, libstdc++ thinks it’s integral only in -std=gnu++XX mode(!), and MSVC thinks it doesn’t exist at all.

At the Kona committee meeting, it was voted (by someone, probably LEWG, I forget the story, I wasn’t in the room) to eliminate the overloaded operator() from C++2a std::span. Now it has only operator[].

# What library types are trivially_relocatable in practice?

In my libc++ fork implementing library support for P1144 “Object relocation in terms of move plus destroy,” I have a unit test that tests std::is_trivially_relocatable_v<X> for every library-provided type X that I can think of. Here is that same list of library-provided types, in convenient tabular format, for each of the Big Three implementations (libc++, libstdc++, and MSVC). The results for libc++ are accurate. The results for libstdc++ and MSVC are my best guesses based on whatever homework I’ve done up to this point. I will endeavor to fix bugs in this table as they are reported.

# compressed_vector_traits

From Slack earlier tonight:

# Quick and unscientific trivially_relocatable benchmark

P1144 [[trivially_relocatable]] is one of those optimizations (like move semantics and copy elision) where you can make a benchmark show any improvement you want, because the whole point of the optimization is to eliminate arbitrarily complicated user code. So for example at C++Now 2018 I showed a 3x speedup on vector<unique_ptr<int>>::reserve; but I could just as well have shown an Nx speedup on vector<deque<T>>::reserve, where the value of N depends purely on your choice of T — could be 2x, could be 20x, could be 200x. (libstdc++’s deque<T> is the pathological case: it’s trivially relocatable but not nothrow-move-constructible. That’s the key to understanding Marc Glisse’s recent libstdc++ patches.)

# Packs of packs

Jason Rice’s interesting (but IMHO too novel) proposal P1221 “Parametric Expressions” is in the pre-Kona mailing. It’s one of these big proposals that claims to solve a whole bunch of perennial problems at once. I bet it would solve maybe half of what it claims, and if you poke a hole in one part, that wouldn’t make the remainder unsalvageable. I’m just going to poke a hole in a hypothetical extension of one part, for the record, so that I don’t have to keep repeating myself on Slack.

# C++ idiom of the day: arrow_proxy

I’m currently working on a reference implementation of P0429R6 flat_map. Here’s a C++ metaprogramming idiom I learned in the process.