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

Read More

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.

Read More

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.

Read More

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.

Read More

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

Read More

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.

Read More