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 larks”; it’s only in Egerton MS 1995 (fols. 55b–58), Lipton says, that we find “an exaltacyon of larks” 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, 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.” 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.

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.

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

Sadly, no combination of these facilities quite achieves ideal behavior for define_static_array. Let’s take a look.

The compiler can merge similar data

GCC itself merges similar initializer_list backing arrays. For example (Godbolt):

void f(std::initializer_list<int>);
int main() {
  f({1,2,3}); // C.0.0
  f({1,2,3}); // C.1.1
}

turns into the assembly directives

  .section .rodata.cst16,"aM",@progbits,16
  .align 8
  .type C.0.0, @object
  .size C.0.0, 12
C.0.0:
  .long 1
  .long 2
  .long 3
  .zero 4
  .set C.1.1,C.0.0

The symbols C.0.0 and C.1.1 are set to the same memory address, because GCC itself can see that the two initializer_list objects should have the same backing array.

This is the most powerful approach, but at the same time the least elegant, because it requires ad-hoc “smarts” built directly into the compiler. For example, we could imagine GCC generating code that merges one list into the tail of another:

void f(std::initializer_list<int>);
int main() {
  f({1,2,3}); // C.0.0
  f({2,3});   // C.2.2
}

C.0.0:
  .long 1
  .long 2
  .long 3
  .zero 4
  .set C.2.2,C.0.0 + 4

but in fact GCC doesn’t generate that code, because nobody has taught GCC that specific trick. Nor will GCC 16 merge the backing arrays of {1,2,3} and {1u,2u,3u} using this technique, again because it hasn’t been taught to.

Merging things at the compiler level also, by definition, works only within a single translation unit (a single .cpp file). If you want to merge things between different TUs, you’ll need help from the linker. Which brings us to…

SHF_MERGE sections

I said GCC 16 wouldn’t merge {1,2,3} and {1u,2u,3u} in the compiler. But if you try this program (Godbolt), you’ll see that the backing arrays are indeed merged at runtime — the same pointer value is printed twice:

template<class... Ts>
void f(std::initializer_list<Ts>... ils) {
  (printf("%p\n", (const void*)ils.begin()) , ...);
}
int main() {
  f({1,2,3},     // C.0.0
    {1u,2u,3u}); // C.1.1
}

The same pointer value is printed twice, despite that we can see GCC emitting two different objects into the assembly file:

  .section .rodata.cst16,"aM",@progbits,16
  .align 8
  .type C.0.0, @object
  .size C.0.0, 12
C.0.0:
  .long 1
  .long 2
  .long 3
  .zero 4
  .align 8
  .type C.1.1, @object
  .size C.1.1, 12
C.1.1:
  .long 1
  .long 2
  .long 3
  .zero 4

The trick here is in the .section directive, which creates an ELF section in the object file with the name .rodata.cst16, the section flag SHF_MERGE (that’s the M in "aM"), and a sh_entsize of 16 bytes. After concatenating every object file’s .rodata.cst16 sections as usual, the linker is permitted (but not required) to treat the contents of this section as an array of 16-byte elements, and to deduplicate any identical elements it finds. Since the 16-byte region starting at C.1.1 matches the 16-byte region starting at C.0.0, the linker is allowed to eliminate the 16 bytes at C.1.1 and point the label C.1.1 at C.0.0 (or vice versa).

The SHF_MERGE trick works across TUs, and even across types. For example, GCC 14+ makes the following four initializer lists share a single backing array at runtime by putting them all into .rodata.cst16 sections with the SHF_MERGE flag set. This works even if the lists appear in different TUs! (Godbolt.)

{1,2,3,4}
{1u,2u,3u,4u}
{0x200000001, 0x400000003} // given little-endian int64
{4.2439915824e-314, 8.4879831654e-314} // ditto

The major optimization-related downside of the SHF_MERGE approach — as it is sketched in the System V ABI document (2001) and as it is implemented in GNU ld as far as I know — is that you can’t use it to merge data elements of different sizes or alignments. GCC 16 won’t merge {1,2} with {1,2,3} because GCC puts the former in section .rodata.cst8 and the latter in .rodata.cst16. (GCC 14 and 15 put the latter in plain old unmergeable .rodata instead, because its size — 12 bytes — isn’t precisely 16 bytes. GCC 16 fixed that.) Basically, GCC has to precommit every data element to a specific “bucket”; the linker will consider merging it only with other elements in its own bucket.

And SHF_MERGE cannot merge parts of elements; it can merge only full elements. So while you might think a “sufficiently smart linker” could merge {2,3} across the conjunction of {1,2} and {3,4}, the SHF_MERGE algorithm by itself will never do that. Some users might even rely on that guarantee (somehow), so I don’t imagine that any linker will ever gain the smarts to do that.

SHF_MERGE | SHF_STRINGS

When an ELF section specifies both SHF_MERGE and SHF_STRINGS, then instead of chunking the section into elements of size sh_entsize bytes, the linker chunks the section into variable-length elements each of which is a null-terminated C-style string. It then deduplicates those strings.

As in the previous subsection, it seems that no linker will merge "ello" into the tail of "Hello"; the SHF_MERGE|SHF_STRINGS algorithm alone will merge only full elements. (In this case, full null-terminated strings.)

The SHF_MERGE|SHF_STRINGS algorithm finds the “elements” of the section by simplemindedly scanning for null bytes; no additional metadata is involved. Therefore, such a section must never contain strings with embedded null bytes. Try the following on your machine:

cat >x.c <<EOF
#include <stdio.h>
int main() {
  puts("p");
  puts(&"qxp"[2]);
  puts("r");
}
EOF
gcc -S x.c -o - | sed 's/qxp/q\\0p/' > x.s
gcc x.s
./a.out

The assembly file x.s should end up containing something like this:

  .section .rodata.str1.1,"aMS",@progbits
.LC0:
  .string "p"
.LC1:
  .string "q\0p"  # Danger!
.LC2:
  .string "r"

and when executed, will print not p p r but rather p r r, because the SHF_MERGE algorithm understands "q\0p" as "q" "p" and eliminates the second "p" as a duplicate. Therefore, a C++ compiler must go out of its way never to store a string literal containing embedded null bytes into such a section.

const char *p1 = "hello world"; // literal in .rodata.str1.1 (SHF_MERGE)
const char *p2 = "hell\0world"; // literal in .rodata (not SHF_MERGE)

In theory, a compiler could place the backing array for an initializer_list<char> into a mergeable string section, and potentially merge the backing arrays for {'x','y','z','\0'} and "xyz". In practice, neither GCC nor Clang does this (yet).

The big disadvantage of SHF_MERGE merging from the C++ compiler’s point of view — the thing that makes it unsuitable for certain use-cases such as merging the duplicate definitions of template parameter objects — is that it is completely optional. It’s legal for a dumb linker to just ignore the SHF_MERGE flag. It would be unwise to rely on SHF_MERGE to take care of merging objects that the C++ standard requires us to merge, such as the duplicate definitions of inline variables or template parameter objects.

And, of course, it would be wrong to place an inline variable into an SHF_MERGE section anyway, because the standard (and common sense) forbids us to merge unrelated inline variables just because they happen to have the same value!

inline constexpr char a[] = "hello world";
inline constexpr char b[] = "hello world";

Here &a == &b is guaranteed to be false; an implementation that made it true would be non-conforming. (Even gcc -fmerge-all-constants will make it true, non-conformingly, only if you remove the inline keyword in both places.)

To handle inline variables, which are deduplicated according to their symbol names rather than their data contents, we need the next approach, which is…

SHF_GROUP, a.k.a. COMDAT sections

For the past twenty-some years, C and C++ compilers have traditionally compiled inline functions, inline variables, and implicit instantiations of function and variable templates into what are called “COMDAT sections.” This feature came late to ELF; the name “COMDAT” apparently comes from Windows NT. For more than you ever wanted to know about COMDAT, see “COMDAT and section group” (Fangrui Song, July 2021).

ELF’s version of COMDAT was basically designed to do exactly what a C++ compiler needs in order to implement inline functions. The compiler can take C++ code such as

inline int f() {
  static int i = 42;
  return ++i;
}

and turn it into a whole group of sections (text, data, rodata, whatever else it needs) — basically a whole mini object file of its own — something like this:

  .section .text._Z1fv,"axG",@progbits,fgroup,comdat
  .globl _Z1fv
_Z1fv:
  movl _ZZ1fvE1i(%rip), %eax
  addl $1, %eax
  movl %eax, _ZZ1fvE1i(%rip)
  ret

  .section .data._ZZ1fvE1i,"awG",@progbits,fgroup,comdat
  .globl _ZZ1fvE1i
_ZZ1fvE1i:
  .long 42

The assembler emits an ELF section of type SHT_GROUP representing the group of sections with “group identifier” fgroup. The linker, at link time, will pick one object file’s fgroup group and throw away the rest.

Now, I simplified that codegen quite a bit. Really, GCC doesn’t make such a human-friendly section group; it dumps each section into its own individual section group (so in this example there will be two different group identifiers, not just one); and GCC also marks both f and i as .weak symbols rather than global. I’m not sure why GCC does these things; I conjecture “intermediate codegen targeting an object format less powerful than ELF” and “compatibility with very old ELF linkers lacking SHT_GROUP support” respectively, but I don’t know. Email and tell me!

COMDAT sections are exactly what you need to implement the definitions of (1) inline functions; (2) implicit instantiations of function templates; (3) the static local variables of inline functions and implicitly instantiated function templates; (4) implicit instantiations of variable templates; (5) inline variables and static inline data members of classes; and probably a few more things I’m forgetting. All of these are entities with names, and C++ requires them to be properly deduplicated by name: &myInlineFunc must have the same pointer value no matter what translation unit you’re in.

Another kind of entity we talked about the other day in “Things define_static_array can’t do” (2026-04-24): template parameter objects of class type. Code like this:

template<A t>
const A *f() { return &t; }

will produce a template parameter object “variable” in its own COMDAT section, like this (Godbolt):

  .section .rodata._ZTAXtl1AEE,"aG",@progbits,_ZTAXtl1AEE,comdat
  .weak _ZTAXtl1AEE
_ZTAXtl1AEE:
  .zero 1

That’s exactly the same strategy the compiler would use for a simple inline variable like

inline const A v;

Now, when the linker deduplicates COMDAT sections, it looks at the group identifier (a symbol name) to decide if two sections are “duplicates” or not. It doesn’t care whether they have the same bytewise contents. That makes sense, because usually the text sections corresponding to instantiations of the same inline function in different TUs won’t be byte-for-byte identical (especially if the two TUs were compiled with different optimization levels). For inline functions, that’s exactly what we need: deduping by name, not by contents.

You might imagine abusing COMDAT sections to do content-addressed deduplication à la SHF_MERGE. We just have to put each element in its own individual section group, with a group identifier based on (the hash of) its contents. For example, instead of

  .section .rodata.str1.1,"aMS",@progbits
.LC0:
  .string "hello"
.LC1:
  .string "world"
.LC2:
  .string "hello"

we could emit

  .section .rodata.str1.hello,"aG",@progbits,group_hello,comdat
  .globl str_hello
str_hello:
  .string "hello"
  .section .rodata.str1.world,"aG",@progbits,group_world,comdat
  .globl str_world
str_world:
  .string "world"

But that would be vastly increase the linker’s burden — not just processing all those tiny sections, but keeping track of all those new global symbols. (We couldn’t use local, internal-linkage symbols anymore, because the linker wouldn’t be helping us to repoint one symbol’s relocations at another.) And the compiler would have to dedupe within the TU: we could no longer refer to "hello" by local symbols like .LC0 and .LC2, but at the same time we couldn’t emit the global symbol str_hello twice in the same TU.

By the way, making symbol names that incorporate hashes of user-provided data is just asking for trouble. See “Hash-colliding string literals on MSVC” (2022-12-31). A hash collision is disastrous; and when someone discovers how to generate hash collisions and starts writing blog posts like the above, you can’t switch out your hash function for a better one because that would break ABI.

So it’s very good that we have different, essentially custom-fitted, tools for deduping inline functions versus string literals.

• Duplicate inline functions must be merged (we forbid false negatives); non-duplicates must not be merged (we forbid false positives). Dupe-ness is decided by symbol name; contents can be different. Duplication need be detected only across TUs; duplication within a single TU is impossible. Use COMDAT sections.

• Duplicate strings can be left unmerged (we permit false negatives), although we still forbid false positives. Dupe-ness is decided by bytewise contents. Duplication should be detected both within and across TUs. Use SHF_MERGE.

Templates and inline variables can also use COMDAT. A downside is that we’d like to merge the definitions of e.g. f<char*> and f<void*> when they’re identical (if nothing in the program compares their addresses), but if dupe-ness is decided by symbol name and those two have different symbols, we’re out of luck. MSVC has a thing called “Identical Comdat Folding” that helps with that. (MSVC’s ICF is a non-conforming optimization, because it doesn’t check the parenthetical above. This can break code: Godbolt).

Initializer-list backing arrays can use SHF_MERGE too. A downside is that we’d really like to merge {2,3,4} into the tail of {1,2,3,4}, and the SHF_MERGE algorithm will never do that. At least the compiler can do that, if someone teaches it to. That compiler optimization “composes” properly with SHF_MERGE. The compiler could even merge {1,2}, {3,4}, and {2,3} into a single 16-byte element {1,2,3,4} with three embedded labels, which could then merge with {1u,2u,3u,4u} at link time:

  .section .rodata.cst16,"aM",@progbits,16
.C.0.0:
  .long 1
.C.1.1:
  .long 2
.C.2.2:
  .long 3
  .long 4

Of course it would be better if the linker could work this out itself; the linker has more information than the compiler and therefore can do a better job of merging elements. It would also be nice if we could do something like SHF_MERGE for literals larger than 32 bytes, and/or literals of lengths that aren’t powers of two. GCC bug #119153 is related.

Contrariwise, C++26 std::define_static_array seemingly cannot use SHF_MERGE, because it cannot tolerate false negatives: C++26 at present requires us to merge all copies of define_static_array(std::array{1,2,3}) into the same place in memory. That’s too bad, because forcing it to use COMDAT (name-addressed) instead of SHF_MERGE (data-addressed) means we cannot take advantage of the latitude C++26 gives us to merge define_static_array(array{1,2,3}) with define_static_array(array{1u,2u,3u}).

Well, we could merge define_static_array(array{1,2,3}) with define_static_array(array{1u,2u,3u}) if we used group identifiers based on a hash of the data! When we tried that on string data above we paid a huge performance penalty as well as a correctness penalty. Here we’d pay only the correctness penalty. It’s still not worth it, IMHO.

Conclusion

Figuring out the best way to “compress” static data using only the tools we’ve got — single-TU ad-hoc compiler smarts, data-addressed SHF_MERGE, and name-addressed COMDAT sections — is a very hard problem. The implementation won’t be optimum in every case.

Maybe we could give future linkers even better tools. For example, now that “potentially non-unique object” is a term of art in C++, maybe we could just dump all PNU objects’ initializers into a single section (.rodata.pnu?) and in one more special section (.pnu_symtab, storing just a list of indices into the real .symtab?) specify their starts and sizes — I think that’s all the information the linker needs in order to overlap them any way it sees fit and repair .symtab accordingly.

Something like that might already exist. If it does, I’d certainly like to hear about it. And if it doesn’t, I’d certainly like someone to build it!

The lines of WOOD0350’s Fortran source (intentionally or not) never exceed 80 columns regardless of your tab stop:

$ detab -4 advent.for | awk '{print length}' | sort -n | uniq -c | tail -4
  48 77
  52 78
  35 79
   3 80
$ detab -8 advent.for | awk '{print length}' | sort -n | uniq -c | tail -4
  58 77
  62 78
  39 79
   3 80

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:

$ detab -4 advent.dat | awk '{print length}' | sort -n | uniq -c | tail -4
  55 71
  59 72
  67 73
  69 74
$ detab -8 advent.dat | awk '{print length}' | sort -n | uniq -c | tail -4
  59 76
  66 77
  69 78
   4 82

These are the four offending lines. The first comes from section 3 (travel table) and the rest from section 9 (bit flags).

108     95556   43      45      46      47      48      49      50      29      30
0       1       2       3       4       5       6       7       8       9       10
7       42      43      44      45      46      47      48      49      50      51
7       52      53      54      55      56      80      81      82      86      87

If your version of Adventure has suffered truncation at the 80th column at any point in its pedigree, you’d expect to see (1) going DOWN from Witt’s End is impossible; (2) the Cobble Crawl does not have light; (3) entering maze room 51 or 87 resets the maze hint counter.

I first became aware of this possibility in December 2025, when Mike Willegal sent me a fan-fold printout of HORV0350 (a SEL32/RTM port of WOOD0350 most recently touched by Ned Horvath) that he’d kept since March 1979. In that fan-fold printout, all four of the lines above are truncated and thus missing the last number.

Now, I have no evidence that HORV0350’s own data file was actually truncated. But anyone retyping the game from that printout could easily have assumed that the Cobble Crawl was meant to be dark, and that Witt’s End was meant to have no DOWN exit.

I see evidence that such truncation really did happen between LONG0501 and ANON0501/OSKA0501.

• ANON0501 reflows line (1), preserving the exits from Witt’s End, but truncates (2) and (3).
• OSKA0501 reflows (1) but truncates (2) and (3).
• MCDO0551 reflows (1) but truncates (2) and (3).
• ROBE0665 reflows all three.

My decompilation of the recovered LONG0751’s data file indicates that it did not truncate any of these lines; and my playtesting of the recovered LONG0501 indicates that it did not truncate (1) or (2) either. (It’s inconvenient to test (3) by playtesting.)

These observations are consistent with the hypothesis that first LONG0501 reflowed (1) but left (2) and (3) untouched; then ANON0501/OSKA0501 and MCDO0551 descended from truncated paper printouts of LONG0501 (or via a now-lost common ancestor that was itself descended from LONG0501 by truncation). Meanwhile LONG0751 and ROBE0665 descended, independently, from non-truncated copies of LONG0501.