Previously on this blog: “The Book of St Albans (1486)” (2026-05-22), in which I made a table of terms of venery, a.k.a. company terms, e.g. “an exaltation of larks,” as in the eponymous book by James Lipton. I mentioned that the Book of St Albans actually has “an exaltyng of larkis,” and that it’s only in Egerton MS 1995 (circa 1450), according to Lipton, that we find “an exaltacyon of larkys” proper. But I couldn’t find any digitized copy of Egerton MS 1995 to verify that claim.

First images of PHerc. 1667. When Vesuvius buried Herculaneum, it turned many papyrus scrolls in the Villa dei Papiri to burnt hunks of carbon without destroying their physical structure. Since the 2010s (or earlier?), people have tried to non-invasively image what remains of the scrolls. In June 2026, the latest “Vesuvius Challenge” prize was awarded to a team who successfully imaged the first “complete” scroll. The team’s report (“Complete virtual unwrapping and reading of a rolled Herculaneum papyrus”, Angelotti et al., 2026) points out that the scroll is even less “complete” than it used to be: invasive efforts in the late 20th century had already reduced it from about 14 grams of carbonized gunk to about 6 grams. The group’s full transcription consists of only 300 to 400 complete words. They identify PHerc. 1667 as some sort of philosophical treatise — unsurprising, as many of the scrolls that could already be deciphered turned out to be works of Philodemus. Contrary to some media reports, the title of PHerc. 1667’s work is unknown; but a separate finding reported in the same paper identifies PHerc. 139 as book 8 of Philodemus’s On gods (περὶ θεῶν, book Η).

From Louis Godart’s The Phaistos Disc: The Enigma of an Aegean Script (1994, tr. Alexandra Doumas):

Keenan Horrigan on the std-proposals mailing list pointed out an interesting consequence of C++26 Reflection: it seems to give us “universal template parameters” almost for free.

A few days ago Christof Kaser posted a very impressive blog post on “Fast Branchless Quicksort using Sorting-Networks” (chkas/blqsort). A “branchless” algorithm is one designed to exploit modern processors’ conditional-move instructions. So for example the blqs::sort2 primitive, which looks like this:

This morning I was reading the umpteenth std-proposals thread proposing some variety of unstable_remove and it occurred to me that one odd thing about a swap-and-pop-based unstable_remove is that it tends to replace large swaths of contiguous removals by reversing the elements that are kept. For example (Godbolt):

This week I read James Lipton’s An Exaltation of Larks; or, The Venereal Game (2nd edition, 1977), a discursive collection and celebration of “terms of venery” — the collective nouns like “school of fish” and “pride of lions” that were (so the story goes) mostly invented by medieval hunters who wanted to have their own proper jargon to distinguish the real hunters from the dilettantes.

is_sorted doesn’t require random access; why should is_heap?

The other day I came across Connie Kleinjans’ page of “two-minute versions” of G&S shows. She’s got two versions of Gondoliers and one each of Iolanthe and Ruddigore. The technique is the same as in blackout poetry: take the whole work and black out all but the most important and/or funniest bits.

Previously I wrote:

[Template parameter objects of array type] are permitted to overlap or be coalesced, just like initializer_lists and string literals. Clang trunk isn’t smart enough to coalesce potentially non-unique objects [but] GCC, once it implements define_static_array, will presumably make them the same.

Well, GCC 16 has an experimental implementation of define_static_array (compile with g++ -std=c++26 -freflection), and it does not coalesce template parameter objects of array type in the way I expected. Digging deeper into why not, I learned that there are at least three ways compilers and linkers (on ELF — that is, non-Windows — platforms) conspire to “merge” potentially non-unique objects:

• Merging at the compiler level (for initializer_list backing arrays)
• Sections with SHF_MERGE (for string literals and backing arrays)
• Sections with SHF_GROUP, a.k.a. COMDAT sections (for inline variables)

The original Colossal Cave Adventure consists basically of a Fortran source file and a textual data file. These files would often travel from one installation to another via paper printouts: printed out at one site, typed in by hand at another.

The lines of WOOD0350’s Fortran source (intentionally or not) never exceed 80 columns regardless of your tab stop. But the data file fits within 80 columns only with a tab stop of four. With an eight-space tab stop, four lines of the data file exceed 80 columns:

On 2012-12-01 I wrote to Don Woods (in a postscript to a production update on Colossal Cave: The Board Game):

By the way, I just noticed last week that in “Adventure”, in the Hall of the Mountain King, the directions NORTH and LEFT are synonyms, as are SOUTH and RIGHT… as are WEST and FORWARD!  West being forward makes sense, if the Hall of Mists is back to the east; but for the rest I suppose the adventurer must be walking on the ceiling. :)  This little mixup is present all the way back to Crowther’s code. I just thought it was funny that nobody had commented on it before, as far as I know.

We’ve seen previously that it’s not possible to create a constexpr global variable of container type, when that container holds a pointer to a heap allocation. It’s fine to create a global constexpr std::array, or even a std::string that uses only its SSO buffer; but you can’t create a global constexpr std::vector or std::list (unless it’s empty) because it would have to hold a pointer to a heap allocation.

Recently it was asked: What’s the difference between the expressions auto(x) and auto{x} in C++23?

Here’s a neat trick to create an “overloaded macro” in C, such that M(x) does one thing and M(x, y) does something else. For example, we could make a macro ARCTAN such that ARCTAN(v) calls atan(v) and ARCTAN(y,x) calls atan2(y,x).

#define GET_ARCTAN_MACRO(_1, _2, x, ...) x
#define ARCTAN(...) GET_ARCTAN_MACRO(__VA_ARGS__, atan2, atan)(__VA_ARGS__)

Previously: “span should have a converting constructor from initializer_list” (2021-10-03). This converting constructor was added by P2447 for C++26. Way back in 2024, Peter Kasting added the same constructor to Chromium’s base::span — he emailed me about it at the time — but I was only recently reminded that in the /r/cpp thread about the feature he’d written:

Yup, this change was so useful it led to me doing a ton of reworking of Chromium’s base::span just so I could implement it there.

Speaking of ambiguity: out of context that comment could be taken as sarcasm. What programmer enjoys “doing a ton of reworking just” to implement a single new constructor? Did he mean the change was so useful, or, like, “so useful”? :) So it’s worthwhile to track down pkasting’s actual commit from November 2024 and see all the places he sincerely did clean up as a result.

The other week I read William Empson’s Seven Types of Ambiguity (first published 1930, third edition 1953 with new footnotes by the author). Empson purports to taxonomize all sorts of “ambiguity,” defined as any technique or nuance “which gives room for alternative reactions to the same piece of language.” Really I’m not sure I fully grasped his taxonomy. (One might call it a taxonomy of ambiguity in more ways than one!) But it’s something like this:

P1064 “Allowing Virtual Function Calls in Constant Expressions,” adopted for C++20, permits you to mark virtual functions as constexpr and then call them at compile-time. In fact, you can even mark them consteval (also a C++20 feature), which means you can call them only at compile-time. Thus (Godbolt):

I wrote in ”[[trivial_abi]] 101” (May 2018), during the active development of the [[clang::trivial_abi]] attribute:

Relation to trivial relocatability: None… well, some?

As you can see, there is no requirement that a [[trivial_abi]] class type should have any particular semantics for its move constructor, its destructor, or its default constructor. Any given class type will likely be trivially relocatable, simply because most class types are trivially relocatable by accident…

A correspondent writes in with a query for Socrates (previously seen on this blog in July 2023).

Epistolographos writes: Actually, I think trivial-abi-ness and trivial relocatability are almost the same thing.