Well, I wrote to the British Library and got the relevant folios digitized; so I can now present a rough transcription of the Egerton manuscript’s venereal passages. (Sadly there is insufficient communication between the Library’s division who scan things for money and the division who publish things in the digital online catalog; I have the scan, but the British Library’s online catalog still will not. Therefore I’ve uploaded it also to the Internet Archive, where — at least for now — you also may view it.)

For brief inventories of the whole contents of Egerton MS 1995, see:

• The British Museum’s catalog entry

• Item 2105 in an 1865 auction catalog of “highly important and valuable books and manuscripts of a nobleman of great literary and artistic taste”

• James Gairdner, The historical collections of a citizen of London in the fifteenth century (Camden Society, 1876)

Do you have a correction or helpful comment on this transcription? Send me an email!

(Fols. 55v ff.)

Note ye the properteys that longythe to a yonge gentylle man to have knowynge of ſuche thyngys that longythe unto hym that he fayle not in hys propyr termys that longythe unto hym as hyt ſhalle folowe hereynne wrytynge ❦

The Condyſcyons of a grehounde ande of hys propyrnyng ~ propyrteys ~

Thy grehounde moſte be heddyd lyke a ſnake
  y-neckyd lyke a drake
  y-breſtyde lyke a lyon
  y-fotyd lyke a noymon
  y-ſyded lyke a noynon
  y-fotyde lyke a catte
  y-taylyd lyke a ratte

Thenne ys the grehounde welle y-ſhapte ~

Termys of venery ❦

Here begynnythe the Termys of kervynge of Fowlys ande of Fyſchyſſe ❦

Alle the Termys that longgythe unto fyſche ~

Explicit ❦

There follows a poem, “Litylle chyldrynne here may ye lere,” which is transcribed in F. J. Furnivall’s Early English Meals and Manners (Early English Text Society #32, 1868). Picking up again at folio 60r:

Here endythe the boke of Curteſy that ys fulle neceſſary unto yonge chyldryn that muſte nedys lerne the maner of curteſy ~

Explicit; Amen.

There was a man that hadde nought,
There come thevys & robbyd hỹ & toke nought,
He ranne owte and cryde nought,
Why ſhulde he crye, he loſte nought,
Here ys a tale of ryght noughte.

Cronica ſi pences ſi certant oxonienſes
Poſt paucos menſes pugnabũt & angliginences

A “Leonine” witticism also attested elsewhere: “The chronicles tell us that when Oxford men contend / in months all England wars from end to end.”

There follows (fols. 60v–61v) a 2.5-page treatise on prophesying by the first windy night after Christmas: Si ventus fuerit in prima nocte Natalis dm̃ in illo anno Reges et Principes Pontifices et ceteri duutes^(?) vel potentes per univerſum orbem ꝑibunt. Secunda die vel in nocte Natalis dm̃ ventus fuerit unia per univerſum orbem frumenta et grana deficient… For an 11th-century variation on this text, see BnF NAL 873, fol. 200r ff.

There follows (fols. 61v–62v) some Latin commentary on the twelve months.

Here benne alle the namys of the byſcheppe richys of alle yngelonde and thoo that longythe unto Yngelonde ~

Canntyrbury, Yorke, Exceter, Bathe, Salyſbury, Wyncheſtye, Worceter, Rocheſter, Cheſter, Lyncolle, Lonndon, Chicheſter, Ely, Syndavy,^(?) Synt Aſfe, Bangor, Herforde, Cardeaffe, Northewiche, Carlylle, Dyrham [Later addition in a blacker ink: Peterborow] — Non plura^(?)
Smⁱⁱ anñ XXIV^(?)

Deo gracias &^(?) Hylle ~

(“Syndavy” might be St David’s, in Wales; I’m surer that “Synt Aſfe” is St Asaph’s. I can’t hazard a guess on the Latin abbreviations, except to note that if “annum 24” is a regnal year, the 24th year of Henry VI’s reign would have been 1448.)

(Fols. 63r ff.)

For a yong gentylle man to knowe the termys of venery and the crafte whyche the iiij beſtys of venery ~ The herte, the hare, the wolfe, and the wylde Bore — Of venery there bynne nomore.

The Beſtys of the Chaſſe as hyt apperythe ~ The Bucke, the Doo, the Roobucke, the Roodoo, the Bere,^(?) and the rayne dere.

The Elke that ys to ſay a herte of II wyntyr age. ¶ The ſpycurde that ys to ſay a herte of III wyntyr of age.

The Fulmer,^(?) the Fechewe,^(?) the Catte of the mountayne, the Gray, the Fox, the Weſylle, the martoun, the ſquyrelle, the Ottyr, the Polkatte — Alle thes benne of the ſtynkyng Fute or ſtynkying Chaſſe, for the wylle bothe clym and crepe as for the ſubſtance of hem ❦

There ben Grehoundys for game and many othyr dyvers houndys ſum^(?) honeſte & ſum profytabylle as hit ſhalle folowe here in wrytynge ❦

Fyrste a Grehounde, a Baſtarde grehounde, a mongrelle, a maſtowe,^(?) aloundys, lymoire — Alle thes ben take in to the leſſe. ¶ Spaynellys, Rangys, Kenellys, Trerors — Alle thes wylle range for to rayſſe uppe the game. ¶ Bocherhoundys, Dunghylle Currys, and ſmalle Popys for ladys Chambers.

Aloundys ben cuſte, lymors drawyn, a Blode hounde or a dogge for the bowe drawythe, kenettys rennyn, ſpaynellys retryvyn. The Terer gothe undyr the gounde for to feſtyn the Fox or the Graye ❦

A hunt caſtythe of a copylle of Alundys unto an herde of hertys. Then he browythe comfortỹg hys houndys. ¶ The herte takythe the water then the herte ſevſythe^(?) [perhaps fuite? cf. Hare’s The Language of Field Sports p16]. Whenne the he ſwỹmythe downe thanne he fletythe. ¶ Whenne that he ſwỹmythe up on the water thenne he brekythe, or brethythe. ¶ When that he ſwỹmythe ovyr thenne he croſſythe. ¶ Whenne he retornythe thenne he croſſythe.^(?) ¶ Whenne that he takythe dry londe thenne he fleythe. ❦

Explicit.

The namys of hawkys and to what maner of Perſonys that they longe unto every man aftyr hys owne degre and ordyr ❦

There longyn unto an Emꝑour thre maner of hawkys ~ That ys to ſay: an Egylle, a vature, a melounde.

And the ſympylyſte of thes wylle ſlee an hynde Calfe by hym ſelfe, or a doys Fawyn, or a Roo, or a crane or a Buſtarde other wyſe namyde a derefoule. Or a ſtorke or a Fox.

¶ And thes hawkys benne not namyd or callyd unto the lewre; the cauſe ys for they ben ovyr hevy & ponderos for any man to bere. ¶ But they ben made unto the Perke portatyf and ther by they benne governyde.

¶ Ther ben hawkys of the Towre ❦

A Gerfaukyn, a Terſelle, a Grfaukyn — for a kynge; a Faukyn Gentylle and a Taſſelle gentylle — For a Prynce; a Faukyn of the Rooke — For a Duke; a Faukyn Peragryne — for an Erle; a Baſtarde — for every lorde; a Saker and a ſakerette — for a knyght; a laner or a lanerette — for a ſquyer; a Merlyon — for a lady; a Hobby — for a yong ſquyer. Alle thes ben hawkys of the Towre ~ And alle thes fleyn fro the lewre.

¶ The Goſhawke ys for a yeman; a ſperhawk for a preſte; a muſkette for a clerke. Ande thes ben made unto the fyſte ande fle w^t hyr fre wylle yf they benne in ther proſpyte for to make game unto hyr mayſter more þen for any gredynys of mete for they ben noo Rayvyners. ¶ And ſum of the hawkys a fore ſayde wylle be made unto the fyſte welle y-nowe, but they moſte gave grete labyr to bryng them there to. ❦

Explicit.

Gret huntyng by ryvers and wode
Makythe a man ys here to growe thorowe hys hoode.

There follows (fols. 65r ff.) “a nobylle tretys of medyſyns for mannys body.”

Three lost songs from Iolanthe. In April 2026, Marc Shepherd was looking at a manuscript full score of Gilbert & Sullivan’s Iolanthe in the British Library (MS Mus. 1824/1/7/4) and discovered at the back of the manuscript the orchestra parts for these three songs, all cut from Iolanthe before the end of its run and up to now believed about as lost as Thespis:

• “On you they’d set a coronet” (Phyllis, Tolloller, Mountararat, Lord Chancellor)
• “My love for him is dead” (Phyllis)
• “De Belville was regarded as the Crichton of his age” (Mountararat)

More information can be found in Shepherd’s transcription of the full score; in his blog post “Three Deleted Songs from Iolanthe” (May 2026); and in a two-hour video interview with William Remmers, the music director of New York’s Utopia Opera. Utopia Opera has already put recordings of all three songs on YouTube.

Shepherd remarks that Phyllis is a soprano without an aria; the deleted song would naturally have been her big number. But Act II already has its share of wishy-washy love songs — “You plead in vain,” “Oh foolish fay” — and “My love for him” must have seemed too samey. Mountararat, meanwhile, is coming straight from his three-verse comic song “When Britain really ruled the waves”; it doesn’t make much sense to give him a second three-verse comic song in the same act! Still, Gilbert liked “De Belville” per se so much that he republished its words in Songs of a Savoyard (1890); it was only Sullivan’s melody that was lost.

Shepherd is also the coauthor of The Variorum Gilbert & Sullivan, Volume 1 (2015) and has edited the full scores of many of the operettas. The most interesting parts of the Utopia interview, for me, were in the first 15 minutes where Shepherd talks about his ongoing projects (including volumes 2–5 of the Variorum); and circa an hour in, where they discuss the importance of a well-edited score and the crazy things one does when one is lacking. The former reminds me that I have plenty of unfinished projects of my own. For example, after I wrote “In search of Adventure ]I[” (2023-01-09) I did actually receive a playable version, which I haven’t gotten around to blogging about yet; nor have I yet written a post about my online collection of John Philip Sousa operettas. The latter reminded me of what George Bernard Shaw said in the third edition of The Perfect Wagnerite:

It is possible to learn more of the world by producing a single opera, or even conducting a single orchestral rehearsal, than by ten years reading in the library of the British Museum.

Yet another proposed decipherment of Linear A. Via Hacker News: “Amateur linguist” Tom di Mino proposes that the Linear A script of Minoan Crete encodes a spoken language from the Semitic family, and claims to have a list of phonetic values that make sense of at least one inscription. He announced the news via LinkedIn and via Stephen Kosloff’s AI-themed blog, which are weird venues: weird enough to attract attention from hackers with Gell-Mann amnesia, for sure.

I hadn’t yet heard this news when I posted “Katakana and Cypriot” (2026-06-12); that was just serendipity. But on that note I observe that you can find some autodidacts (and even allodidacts) who unironically claim that Linear A encodes spoken Japanese; notably Gretchen E. Leonhardt and Mizuhiro Kuroda. Needless to say, it does not.

Hat sighting in the wild. Last week I visited ArtsWestchester in White Plains, New York, which is housed in a former bank and occasionally uses its armored vault for art installations. This month it’s Rana Amirtahmasebi’s “Continuum: Terra,” in which the artist covers various things (walls, floors, dishes) with the aperiodic monotile known as the “hat.” The hat itself is a recent discovery — it was first discovered in 2022 and announced publicly in March 2023.

ArtsWestchester’s official gallery page inexplicably displays an AI-generated image of some bullshit, rather than Amirtahmasebi’s actual work. What, does nobody at ArtsWestchester own a camera? Top: ArtsWestchester’s AI slop. Middle and bottom: The real-life vault, with hat pattern.

Now, the hat will tile the plane, but you’ll have trouble tiling a curved surface (such as Amirtahmasebi’s lumpy pottery). Her solution was in some cases to deform or truncate the hat, and in other cases to just give up and stop tiling. It wasn’t mathematically satisfying at all. But I liked seeing the hat in the wild, anyway.

See also:

• “Two-Minute Iolanthe” (2026-05-08)
• “Escheresque parquet deformations of an aperiodic monotile” (2023-03-30)

Whoever studies the history of writing, ancient or modern, should be mindful of one basic methodological principle: a comparison between the signs encountered in different scripts should always be treated with skepticism and subjected to severe criticism. There are plenty of examples of signs that are graphically the same, and indeed have the same phonetic value, in scripts that have absolutely nothing in common. A case in point are the nine signs in the classical Cypriot syllabic script, in use on Cyprus until the fourth century BC, and modern Japanese. The signs YE [sic], VE [sic], RO, SE, TO, KO, RU, ME, and PE are written in exactly the same way in both, without anyone ever even imagining an affinity between the script of ancient Cyprus and the kana script of Japan.

These days both katakana and the Cypriot syllabary are encoded in Unicode, so it’s convenient to present the following table of glyphs that (according to their Unicode character names) represent the “same” phonetic values:

See also a nice diagram of a few of these on page 11 of Francesco Soldani’s doctoral thesis “Interconnessione grafica tra i vari sillabari egei e loro leggibilità” (University of Milan, 2013).

The STL sometimes tries to pretend we have “universal template parameters” by overloading templates with the same name. For example, we have both std::get<T>(tp) taking a type and std::get<I>(tp) taking an integer; but these are just two completely different signatures of std::get in the same overload set. Likewise in C++23 you can write either rg | ranges::to<std::vector<int>>() (where the argument to to is a type) or rg | ranges::to<std::vector>() (where the argument is a class template). Again this is accomplished with an overload set — roughly like this (modulo I’ve totally mangled the actual job of ranges::to, which is generally not to forward its arguments to To’s constructor):

template<class To, class... Args>  // #1
auto rangish_to(Args&&... args) {
  return To(std::forward<Args>(args)...);
}
template<template<class...> class To, class... Args>  // #2
auto rangish_to(Args&&... args) {
  return To(std::forward<Args>(args)...);
}

int *a, *b;
auto x = rangish_to<std::vector<int>>(a, b);      // OK, #1
auto y = rangish_to<std::vector>(a, b);           // OK, #2

But even this overload set won’t accept a caller like:

auto z = rangish_to<std::ranges::subrange>(a, b); // error

because std::ranges::subrange as a template argument matches neither class To nor template<class...> class To. It’s actually a class template of two type parameters and a constant! (cppreference.)

enum class subrange_kind : bool {
  unsized,
  sized,
};
template<
  input_or_output_iterator I,
  sentinel_for<I> S = I,
  subrange_kind K = sized_sentinel_for<S, I> ? sized : unsized>
class subrange { ~~~~ };

We could accept subrange ad-hoc via a third overload:

template<template<class,class,auto> class To, class... Args>  // #3
auto rangish_to(Args&&... args) {
  return To(std::forward<Args>(args)...);
}

but in general there’s no way to write out the set of all possible kinds of class templates, so we can’t make our rangish_to accept all of them.

You might point out that the real ranges::to wouldn’t accept subrange anyway, because the real ranges::to accepts only containers like vector, not views like subrange or span. However, this deficiency is likely to be DR’ed in the near future thanks to Hewill Kang’s well-received P3544 “ranges::to<view>.”

C++26 Reflection to the rescue! C++26 Reflection is “untyped”: it uses a single type std::meta::info to represent the reflections of every kind of thing in the language. Therefore a template parameter of type meta::info alone can represent std::vector, std::ranges::subrange, std::array, or anything else (std::vector<int>, size_t, 42, std::ignore…) and so we can write a single function template like this (Godbolt):

template<std::meta::info To, class... Args>
auto meta_to(Args&&... args) {
  return typename [:To:](std::forward<Args>(args)...);
}

auto x = meta_to<^^std::vector<int>>(a, b);      // OK
auto y = meta_to<^^std::vector>(a, b);           // OK
auto z = meta_to<^^std::ranges::subrange>(a, b); // OK!

For the cost of two characters ^^ (and a really cryptic error message if you forget the typename keyword), C++26 seems to have given us universal template parameters!

(Does this mean P2989 “Universal template parameters” is obsolete? IMHO, yes. But I can see how one might debate it: those two ^^ characters are kind of ugly.)

template<class T, class Compare>
void sort2(T& a, T& b, Compare comp) {
  T x = a;
  T y = b;
  bool m = comp(x, y);
  a = m ? x : y;
  b = m ? y : x;
}

when instantiated for int compiles down to a couple of cmov instructions on x86-64 and a couple of csel instructions on ARM64. (Godbolt.)

But at the higher generic-programming level, count all the copy operations in sort2! It copies a into x; then copy-assigns x back into a. If T were an expensive-to-copy type like std::string, this would be slow code; and if T were unique_ptr, it wouldn’t compile at all. Therefore, blqsort enables its entire branchless “fast path” only for types that are trivially copyable and roughly register-sized.

As of this writing the gating condition is std::is_trivially_copyable<T>::value && sizeof(T) <= 16, but I’ve pointed out to Christof that his heap_sort also depends on T to be trivially default-constructible. It’s also possible (if pathological) for T to be trivially copyable yet not copy-constructible or (more commonly) not copy-assignable. But this blog post isn’t really about narrowing the gate; we’re going to broaden it instead!

“Trivially copyable” is what I call a “holistic” trait: it means something about the behavior of the entire type, rather than about just one special member function or just one kind of expression. And specifically what it means is that you can do any value-semantic operation — bringing new copies into existence, poofing them out of existence, overwriting one’s value with another’s, swapping or permuting or copying — as if the objects were just bags of bits. As long as you never try to invent a new value out of whole cloth, you can shift copies of your given values around as much as you like, even into completely new areas of memory, simply by memcpying them. In the following diagram, each box represents a C++ object, and the color of the box represents the object’s value (for example 42, or 3.14, or “hello,” or Tuesday).

We see that in the “After” picture, the green object has become blue. Was that by copy-assignment from the original blue object? or move-assignment? or copying from the yellow, destroying, and then copy-constructing from a blue object? With trivial copyability, we needn’t say! Each of those possible operation-sequences is guaranteed to be physically tantamount to simply memcpying the “blue” bytes into their final location.

“Trivially relocatable” (the widely deployed P1144 idiom, I mean, not the unusable version that was briefly merged into the C++26 draft in 2025) is another “holistic” trait. Specifically what trivially relocatable means is that you can do any affine value-semantic operation — swapping, permuting, relocating from one place to another — as if the objects were just bags of bits. As long as you preserve the number of copies of each given value, you can shift that particular set of values around as much as you like, even into completely new areas of memory, simply by memcpying them. (But unlike two paragraphs ago, with trivially relocatable you’re not allowed to turn one value into two, or poof a value completely out of existence: each and every input value must be represented the same number of times in the final output.)

As long as whatever highest-level algorithm we’re doing preserves this “affine,” one-to-one property, every possible operation-sequence is guaranteed to be physically tantamount to simply memcpying the bytes around.

The above images come from a ten-slide presentation on holistic traits I wrote in mid-2024. See the whole slide deck here.

Algorithms that have this “affine” one-to-one property include swap, rotate, partition, and… sort! Imagine rewriting blqs::sort2 like this (Godbolt):

template<class T, class Compare>
void sort2(T& a, T& b, Compare comp) {
  union U { T t; U() {} ~U() {} };
  U x, y;
  std::relocate_at(&a, &x.t);
  std::relocate_at(&b, &y.t);
  bool m = comp(x.t, y.t);
  std::relocate_at(m ? &x.t : &y.t, &a);
  std::relocate_at(m ? &y.t : &x.t, &b);
}

This is conceptually closer to what our sort2 algorithm actually “needs” to do. It doesn’t really care that it’s making copies of T objects; conceptually it’s just bringing the values “closer to hand” (which could be a relocate), comparing its close-up copies, and then putting the values back “in memory” (which could be a relocate). For trivially copyable T, it’s totally fine to replace the first relocate with a copy-construct and the second relocate with a copy-assign: the end result is guaranteed to be the same, assuming it compiles at all. The relocation-based version merely extends that guarantee from “trivially copyable T” to “trivially relocatable T.”

But the above code both depends on P1144/P3516 relocate_at and is super ugly. Imagine patching every helper in blqsort.h with this pedantry! We can actually achieve the same effect much more easily by leaning on the holistic guarantee: We know that the end result of sort2 — in fact the end result of blqsort — will be an affine, one-to-one, permutation of the input values. So we can actually run the whole algorithm working entirely with object representations! The patch for this is only a few lines long:

  constexpr bool copy_is_cheap =
    std::is_trivially_copyable<T>::value && sizeof(T) <= 16;

+ constexpr bool relocate_is_cheap =
+   std::is_trivially_relocatable<T>::value && sizeof(T) <= 16;

  if constexpr (copy_is_cheap) {
    blqsort(first, last - 1, comp);
+ } else if constexpr (relocate_is_cheap) {
+   struct Rep {
+     alignas(T) char data_[sizeof(T)];
+   };
+   blqsort((Rep*)first, (Rep*)(last - 1),
+     [&](const Rep& a, const Rep& b) { return comp(*(const T*)&a, *(const T*)&b); });
  } else {
    block_qsort(first, last - 1, comp);
  }

This says, “If we know that T is trivially relocatable, then let’s just pretend we’re sorting anonymous blocks of bytes instead. Make sure to treat them as T objects for the purposes of comp, but don’t worry about the value-semantic bookkeeping; I promise it will all come out correctly in the end.”

Christof’s blqs::sort uses the branchless fast path, blqsort, only for trivially copyable types; types that don’t make it through that gate will use the slow path, block_qsort, instead. This patch broadens the gate: now we can use the fast path for all trivially relocatable types, including for example unique_ptr and shared_ptr. (But not string, because it fails the sizeof check.)

Benchmark results

This turns out to be a perfect testbed for the kinds of performance improvements you can get from P1144-style trivial relocation on something as familiar as sorting a vector of shared_ptr. I wrote a benchmark (backup) comparing the performance of the high-level blqs::sort on four different kinds of T:

struct TC {
  Int *p_;
  void *ctrl_;
  explicit TC() = default;
  explicit TC(Int& i) : p_(&i) {}
  friend auto operator<=>(const TC& a, const TC& b) { return *a.p_ <=> *b.p_; }
};

struct TR {
  std::shared_ptr<Int> p_;
  explicit TR() = default;
  explicit TR(Int& i) : p_(&i, [](Int*){}) {}
  friend auto operator<=>(const TR& a, const TR& b) { return *a.p_ <=> *b.p_; }
};

struct NTC : TC {
  using TC::TC;
  ~NTC() {}
};

struct NTR : TR {
  using TR::TR;
  NTR(NTR&&) = default;
  NTR(const NTR&) = default;
  NTR& operator=(NTR&&) = default;
  NTR& operator=(const NTR&) = default;
  ~NTR() {}
};

TR is a Rule-of-Zero type that pays all the same costs as shared_ptr for its value-semantic operations — yet it is trivially relocatable. Then NTC is exactly the same as TC except that its no-op destructor makes it not-trivially-anything; and NTR is exactly the same as TR (paying shared_ptr costs) except that its no-op destructor makes it not-trivially-anything.

Sorting a vector of 50 million elements with Christof’s (current) implementation of blqs::sort out of the box shows TC taking the fast path and all three of TR, NTC, NTR taking the slow path, as predicted. Here the “std::sort” column refers to libc++’s current implementation.

Now we apply the patch above, to enable the fast path whenever relocate_is_cheap. The numbers for TC, NTC, and NTR aren’t expected to change; so you can see roughly how noisy this microbenchmark is.

That is, by applying an eight-line patch to use the fast path for trivially relocatable shared_ptr, we’ve turned blqs::sort from a 4% win into a 38% win, right in line with its speedup for trivially copyable types.

What gave us this speedup?

To get this speedup, we used one “dirty trick” and one compiler extension. Our dirty trick was:

struct Rep {
  alignas(T) char data_[sizeof(T)];
};
blqsort((Rep*)first, (Rep*)(last - 1),
  [&](const Rep& a, const Rep& b) { return comp(*(const T*)&a, *(const T*)&b); });

Those casts are reinterpret_cast in disguise. This is type-punning, and technically it’s undefined behavior. (It’s certainly not constexpr-friendly.) We can make it well-defined and constexpr-friendly by using the P1144/P3516 entrypoint std::relocate_at on T objects instead of copy-assignment on Rep objects; but as we’ve seen, that’s very ugly — and in fact very error-prone. Changing a copy-assignment-based algorithm to use relocation takes a major code audit to make sure you balanced out every construction and destruction, never moved or relocated twice from the same object, never accessed an object outside its lifetime, etc. Our “dirty trick” foolproofly accomplished the same codegen, with just a little surgical patch at the top level. If we really needed constexpr-friendliness, I’d add an if consteval at the top level sooner than I’d give up this trick.

But of course the thing we must have, in order to apply this optimization, is a reliable way to detect is_trivially_relocatable<T>. My code makes it look easy, because I use a compiler (and standard library) with full P1144 support. Sadly neither Clang nor GCC is such a compiler.

Mainline Clang actually has two different builtins in this area — __is_trivially_relocatable and __builtin_is_cpp_trivially_relocatable — but both of them have too many false positives to use safely in production: the latter by design (it intended to implement the failed P2786 proposal) and the former merely by neglect. An attempt was made to fix up the former in Clang #84621, but the maintainers resisted, and the patch was eventually abandoned. Obviously I’d like to see it revived.

template<class BidirIt, class Pred>
BidirIt unstable_remove_if(BidirIt first, BidirIt last, Pred pred) {
  while (true) {
    first = std::find_if(first, last, pred);
    if (first == last) return first;
    while (true) {
      --last;
      if (first == last) return first;
      if (!pred(*last)) break;
    }
    *first++ = std::move(*last);
  }
}

int main() {
  auto in234 = [](int x) { return 2 <= x && x <= 4; };
  std::vector<int> v = {1,2,3,4,5,6,7,8,9};
  v.erase(unstable_remove_if(v.begin(), v.end(), in234), v.end());
  // v is {1,9,8,7,5,6}
}

It would be more aesthetically pleasing to produce {1,7,8,9,5,6}: for trivially copyable elements, this would be a single memmove. In a sense, “reversing the elements” is extra work that we might save time by avoiding. But to avoid that work, we might have to do even more work in the form of bookkeeping. I haven’t attempted to benchmark any such change to unstable_remove.

But the same aesthetic consideration applies to the ordinary, stable std::remove_if. Traditionally it’s a loop over operator=, like this:

template <class FwdIt, class Pred>
FwdIt smooth_remove_if(FwdIt first, FwdIt last, Pred pred) {
  FwdIt dfirst = std::find_if(first, last, pred);
  if (dfirst != last) {
    for (first = std::next(dfirst); first != last; ++first) {
      if (!pred(*first)) {
        *dfirst++ = std::move(*first);
      }
    }
  }
  return dfirst;
}

But what if we “chunked” the writes to *dfirst, like this?

template <class FwdIt, class Pred>
FwdIt chunky_remove_if(FwdIt first, FwdIt last, Pred pred) {
  FwdIt dfirst = std::find_if(first, last, pred);
  if (dfirst != last) {
    for (first = std::next(dfirst); first != last; ++first) {
      if (!pred(*first)) {
        FwdIt sfirst = first;
        first = std::find_if(std::next(first), last, pred);
        dfirst = std::move(sfirst, first, dfirst);
        if (first == last) break;
      }
    }
  }
  return dfirst;
}

Delegating the work to the std::move algorithm allows the library to use memmove for that work, if the element type happens to be trivially copyable. The nested loop complicates the generated code (Godbolt), but is it worth it? Do we actually save CPU cycles?

Well, if the average length of a “run” of survivors is long, then we might expect the cost of a single large memmove to beat out the cost of operator=-in-a-loop. But at the other extreme, if the average length of a run is only 1 element, then memmove won’t save anything; we’ll be paying all the bookkeeping cost for none of the benefit.

By “bookkeeping” I mean not only the extra register and icache pressure of the more complicated algorithm, but also the overhead of the call to memmove itself, and that memmove will necessarily start by checking whether it needs to handle forward overlap. (That branch is completely predictable — it doesn’t — but is still overhead absent from the “smooth” version.)

I wrote a little benchmark (backup) to time a call to std::remove_if on an array of a million ints, with a bit-masking predicate that removed half of the elements; one in 8; one in 128; or one in 1024. I contrived this benchmark deliberately to play to the “chunky” algorithm’s strengths: trivially copyable elements, with large swaths moved contiguously.

The “smooth” column here is merely to prove that my smooth_remove_if implementation is essentially the same as libc++’s default implementation: my chunky_remove_if can’t blame its defeat on “library vendor magic.” Yet it is defeated, and decisively so:

As expected, chunky_remove_if loses when the expected length of a memmove is short. But it also loses when the expected length of a memmove is long! And, counterintuitively, as we remove fewer elements (and thus execute more individual assignments in the “smooth” case and fewer individual memmoves in the “chunky” case), smooth_remove_if gets faster and faster, and chunky_remove_if’s performance penalty doesn’t budge.

I tentatively blame this on the branch predictor. The fewer elements we remove, the more predictable the result of pred(*first). Removing half the elements is the worst case for smooth_remove_if simply because that turns it into a tight loop over a single completely unpredictable branch. Making that branch more predictable dominates every other consideration, including any speedup we might get from memmove (which, after all, is also a tight loop over a mostly predictable branch: “have we counted all the way to n yet?”)

Conclusion: “Chunking” the elements moved by remove_if into larger memmoves isn’t an optimization; it’s a pessimization.

This doesn’t directly say anything about unstable_remove, but it does suggest that when it comes to benchmarking remove-related algorithms, we ought not to rabbit-hole on simply minimizing the number of move-assignments; that kind of thing may be outweighed by cache and branch-prediction effects.

Hark ye! Only last week that jack-fool, the young Lord of Brocas, was here talking of having seen a covey of pheasants in the wood. One such speech would have been the ruin of a young squire at the court.

—Arthur Conan Doyle, Sir Nigel (1905)

Lipton’s starting point was a list of 164 terms for “the companies of beasts and fowls” included — merely to fill out the last few pages of a signature (so says William Blades’ excellent preface) — in the Book of St Albans (1486). But from Lipton’s entertaining notes we can see he modernized a few of the terms; for example, he discusses his difficulty in rendering the term “corueseris” (corvisers) for modern readers, and ultimately lands on “shoemakers.” This led me to wonder exactly what other changes Lipton might have snuck in, and therefore to look up the original orthography of the Book of St Albans. That orthography is visible today both in Blades’ facsimile and in Unicode transliteration at Project Gutenberg. I was surprised to find that Lipton’s title, in the Book of St Albans, is rendered as “an exaltyng of larkis”; it’s only in Egerton MS 1995 (fol. 56r) that we find “an exaltacyon of larkys” proper.

C. E. Hare, in The Language of Field Sports (2nd edition 1949) — which Lipton cites! — points out that many of the Book’s terms are not really “company terms.” For example, “a couple or pair of bottles” is no more a company term than “a brace of pheasants” or “a trio of tenors”; and as far as I can tell, “a cast of bread” parallels our “loaf of bread”: no more a company term than “a jug of wine.”

Hare’s notes on the Book are well worth reading. See pages 232–239 for his collection of neologisms including “a glitter of flying-fish” (R. Beale), “a sending of robins” (L. Dawson Campbell), and “a scold of magpies.”

Hare credits “a scold of magpies” to Country Life magazine; but searching that periodical I find only a Letter to the Editor from J. H. Owen (in the 1941-09-26 issue) on the subject of “Congregations of Magpies” which also uses the terms “flock” and “party” but never (as noun nor verb) “scold.”

Here are the terms of venery from the Book of St Albans and from Egerton MS 1995, starting with those for beasts and fowls that might be considered “serious,” and followed by those for human beings of various professions which we might consider “jocular.” The original makes no such distinction: serious and jocular are thoroughly intermixed. My tables appear in alphabetical order, except that I’ll start as the Book does with “herd,” a term associated with the royalty of the animal world.

The jocular terms for companies of human beings and/or inanimate objects:

Leaving An Exaltation of Larks behind, the next list in the Book of St Albans interested me because I had serendipitously just seen it quoted in H. H. Furness’s notes on Love’s Labours Lost, regarding the use of the technical term “break up” in IV.i:

COSTARD: I have a letter from Monsieur Berowne to one Lady Rosaline.

PRINCESS: O, thy letter, thy letter! He’s a good friend of mine. Stand aside, good bearer.—Boyet, you can carve; Break up this capon.

In fact the Book of St Albans says that a capon is not “broken up” at table but “sawsed.” One might guess (as Henry Scougal apparently does in his 1789 New Academy of Compliments) that that word means “sawn,” i.e. “cut up,” but in fact it means “sauced.”

Many of these terms are repeated, as commands, in Wynken de Worde’s Boke of Kervynge (1508).

Note the difference between St Albans’ “an ele trousoned” and Kervynge’s “trassene that ele.” (Egerton has “trowsed.”) Charles Cooper in The English Table in History and Literature (1929) splits the difference and writes “traunsene an eel.” A comic poem in the Literary Gazette of 1827-06-23 has “eels were transened.” A correspondent in Notes & Queries (January 1918) mangles it all the way to “transom an eel.” I’ve gone with “trassened” for no particular reason.

Note that the two Bokes swap their verbs for bittern and curlew: you unjoint the one and untach the other, but they can’t decide which is which. Some modernizations have “untack that curlew,” but untach (like tranch) seems to be good old French: already in Middle English tachen means “pin together,” and so untach would mean “take apart.” (Another sense of tachen relates to a visible token predictive of tetchiness.)

Finally, the Book of St Albans provides a short list of words for when animals bed down for the night:

The hare in her form is proverbial for being snug-fitting and inconspicuous (like a sea hare in its own habitat), as in Jonathan Swift’s poem on mint-master for Ireland William Wood (1725):

The next is an Insect we call a Wood-worm,
That lies in old Wood like a Hare in her Form.

The shallow temporary scrapes of rabbit or roe posed a hazard to hikers: stepping into one and taking a tumble, one might find oneself “in a scrape.” (Eclectic Magazine July 1865.) Similarly, if one took a tumble aboard ship, one might be said to be “scuppered.” (“Scupper,” Notes & Queries 1910-10-08).

A to B: “Mr. C reminds me of a hare.” — “In what way?” — “In that he’ll always lie in a scrape.”

The opposite of “in her form” is “in relief,” i.e., “standing out” (cf. bas-relief). Reverse the syllables and you get lièvre, the French for “hare,” which relates to livre as coney does to coin (i.e., not at all).

template<class A>
auto extract_container(A& a) {
  struct UnwrapAdaptor : A { A::container_type& cc = A::c; };
  return UnwrapAdaptor(a).cc;
}

template<class Adaptor>
void test_push_range(bool is_heapified) {
  int in1[] = {1,3,7};
  int in2[] = {2,4,5,6};
  int expected[] = {1,3,7,2,4,5,6};
  Adaptor a;
  a.push_range(in1);
  a.push_range(in2);
  if (auto c = extract_container(a); is_heapified) {
    assert(std::ranges::is_heap(c));
    assert(std::ranges::is_permutation(c, expected));
  } else {
    assert(std::ranges::equal(c, expected));
  }
}

int main() {
  test_push_range<std::stack<int>>(false);
  test_push_range<std::queue<int>>(false);
  test_push_range<std::priority_queue<int>>(true);
}

I tried to extend main to test also some non-default containers. (Incidentally, did you know stack’s default container is deque, not vector?)

  test_push_range<std::stack<int, std::vector<int>>>(false);
  test_push_range<std::stack<int, std::list<int>>>(false);

…And suddenly the unit test no longer compiled!

error: no matching function for call to object of type 'const __is_heap'
   22 |     assert(std::ranges::is_heap(c));
      |            ^~~~~~~~~~~~~~~~~~~~
[...]
note: because 'std::list<int> &' does not satisfy 'random_access_range'

That caught me by surprise. Why should testing whether a range is heapified require random access? It’s simple to implement with only forward traversal, and make_heap/is_heap seems to analogize perfectly against sort/is_sorted. is_sorted doesn’t require random access; why should is_heap?

Note that is_partitioned only needs to view one element at a time, and remember the boolean value of pred(elt). By contrast, is_sorted, adjacent_find, and is_heap need to view two elements at a time; that’s why they can’t handle input_range.

The two “could bes” in the table above seem to indicate a design defect.

Benchmark it!

libc++’s implementation of std::is_heap looks shockingly inefficient: its 24 lines spend a lot of time recomputing subexpressions like __first + __c (to get to the c’th element) and 2 * __p + 1 (to compute the child index from the parent). A straight-line implementation, avoiding all arithmetic and just advancing two iterators in lockstep, would have taken only 18 lines:

template <class _Compare, class _ForwardIterator, class _Sentinel>
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 _ForwardIterator
__is_heap_until(_ForwardIterator __first, _Sentinel __last, _Compare&& __comp) {
  _ForwardIterator __child = __first;
  if (__child == __last) {
    return __child;
  }
  while (true) {
    ++__child;
    if (__child == __last || __comp(*__first, *__child))
      break;
    ++__child;
    if (__child == __last || __comp(*__first, *__child))
      break;
    ++__first;
  }
  return __child;
}

Surprisingly, libstdc++ and MS STL also spend time adding and dividing (or shifting) when they don’t need to.

Still, just because a piece of code looks inefficient doesn’t always mean that it is inefficient. So I whipped up a simple benchmark:

void BM_vector_half(benchmark::State& state) {
  auto n = state.range(0);
  auto v = std::vector<unsigned>(n);
  std::mt19937 g;
  std::generate(v.begin(), v.end(), g);
  std::make_heap(v.begin(), v.begin() + (n / 2));
  for (auto _ : state) {
    benchmark::DoNotOptimize(v);
    auto it = std::is_heap_until(v.begin(), v.end());
    benchmark::DoNotOptimize(it);
  }
}

vector_full is the same but with make_heap(v.begin(), v.end()). deque_{half,full} are the same but with deque instead of vector.

Here’s the benchmark result before and after applying the patch above to libc++. In this case, our eyes don’t lie: what looks inefficient is inefficient! (Note that our comparator here is less<int>, which is cheap. An expensive comparator could dwarf the cost of arithmetic, making the benefit of this patch less perceptible.)

Even with the current specification of is_heap, we can achieve this performance today. The algorithm can remain constrained on random_access_range (thus doing nothing to solve the motivating use-case that introduced this post) while internally using nothing more than forward-iterator operations. But once the algorithm uses nothing more than forward-iterator operations… wouldn’t it be nice for the Standard to say so?

Conclusions

• libc++ should improve its is_heap implementation along the lines above, reaping the performance benefit.

• So should libstdc++ and Microsoft STL, I expect.

• WG21 should consider relaxing the constraint on is_heap and is_heap_until from “random access” to “forward,” incidentally solving my original use-case. I’ll probably bring a paper to this effect at some point. Note that if such a paper were adopted, all three vendors would have to change their implementations to the faster one.

UPDATE, 2026-07-07: Louis Dionne has added an official libc++ benchmark for is_heap (llvm-project#207045).

Kleinjans’ short scripts are funny in their own rights, but I wanted audio versions; so I made one. Presenting “Two-Minute Iolanthe in five minutes”.

The original recording I “blacked out” for this video is a TV broadcast of a 1976 production at the Sydney Opera House featuring Rosemary Gunn (Iolanthe), Heather Begg (Fairy Queen), Dennis Olsen (the Lord Chancellor), June Bronhill (Phyllis), Lyndon Terracini (Strephon), Graeme Ewer (Mountararat), Ronald Maconaghie (Tolloller), and Alan Light (Private Willis). This is a low-quality VHS rip of an excellent performance.

The VHS rip on YouTube is missing a chunk of the finale, which prompted some alterations to the script; I made a few other alterations for pacing. Even after those cuts, this “two-minute” Iolanthe is almost five minutes long; watch at 2.3x speed for a true two-minute experience.

To create the video, I used ffmpeg to clip and concat the snippets. When concatenating 169 tiny snippets, your biggest problem will be “timestamp drift” between the audio and video channels. I spent a long time cajoling ChatGPT into giving me new permutations of command-line switches to try before finally settling on the programs linked below.

Step 1 was to get the original video (2.4 gigabytes, saved as input.mkv):

brew install ffmpeg yt-dlp
yt-dlp 'https://www.youtube.com/watch?v=DLYSZN2IqeU'

Step 2 was to snip the constituent bits via ffmpeg commands. I factored out the common arguments into environment variables so I didn’t have to keep typing or tabbing over them.

PREFIX="-y"
SUFFIX="-i input.mkv -c:v libx264 -preset veryfast -crf 20 -c:a aac"
ffmpeg $PREFIX -ss 00:07:07.2 -to 00:07:10.5 $SUFFIX part001.mkv
ffmpeg $PREFIX -ss 00:07:45.0 -to 00:07:48.6 $SUFFIX part002.mkv
~~~~

ffmpeg turns out to be supremely sensitive to whether you put the input (-i input.mkv) before, or after, the -ss and -to switches. With -i input.mkv as part of the SUFFIX, my whole script.txt runs in 61 seconds; as part of the PREFIX, it takes 98 minutes.

To concatenate all those clips and re-encode a “preview” video, we can do this:

rm list.txt
for i in part*.mkv ; do echo "file $i" >>list.txt ; done
ffmpeg -y -f concat -safe 0 -i list.txt \
  -c:v libx264 -crf 20 -preset veryfast -c:a aac -ar 48000 output.mp4

Step 3 was to fight timestamp desynchronization. My solution here was generated entirely by blind fumbling and incantations, with input from ChatGPT. It seems that there are basically two ways to get ffmpeg to “supercut” a video as we’re doing here: either clip out the clips into temporary files and then concatenate all those little files (as we did above — this way causes a lot of drift), or do one big “filter” operation to take just the frames you care about in a single ffmpeg invocation. That looks like this, except with 169 clips instead of 3:

ffmpeg -y -i input.mkv -filter_complex \
 "[0:v]trim=start=427.2:end=430.5,setpts=PTS-STARTPTS[v0];
  [0:a]atrim=start=427.2:end=430.5,asetpts=PTS-STARTPTS[a0];
  [0:v]trim=start=465.0:end=468.6,setpts=PTS-STARTPTS[v1];
  [0:a]atrim=start=465.0:end=468.6,asetpts=PTS-STARTPTS[a1];
  [0:v]trim=start=616.5:end=618.7,setpts=PTS-STARTPTS[v2];
  [0:a]atrim=start=616.5:end=618.7,asetpts=PTS-STARTPTS[a2];
  [v0][a0][v1][a1][v2][a2]concat=n=3:v=1:a=1[v][a]"
  -map [v] -map [a] \
  -c:v libx264 -crf 20 -preset veryfast \
  -c:a aac -b:a 192k -ar 48000 \
  output.mp4

That’s horribly slow; it seems to have quadratic behavior as the number of clips increases. Even worse is trying to use the non-“complex” filter options -vf and -af:

ffmpeg -y -i input.mkv \
  -vf "select=between(t,427.2,430.5)+between(t,465.0,468.6)+between(t,616.5,618.7),setpts=N/FRAME_RATE/TB" \
  -af "aselect=between(t,427.2,430.5)+between(t,465.0,468.6)+between(t,616.5,618.7),asetpts=N/SR/TB" \
  -c:v libx264 -crf 20 -preset veryfast \
  -c:a aac -b:a 192k -ar 48000 \
  output.mp4

That just makes ffmpeg run out of memory before you’ve even hit 50 clips. So I ended up using a hybrid approach: I used -filter_complex to produce nine intermediate concatenations of 20 clips at a time, and then used

ffmpeg -y -f concat -i list.txt -c copy output.mp4

to paste those nine files together. I’ve saved my programs for posterity: script.txt runs as a Bash script (in just over 1 minute on my machine) to create that “draft preview” video output; its textual contents also serve as input to script.py, which creates the final product (in about 9 minutes) using the two-level -filter_complex approach. The finished output.mp4 is about 42 megabytes in size.