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

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

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

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

Previously I wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Relation to trivial relocatability: None… well, some?

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

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

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

I recently read, and enjoyed, David Owen’s “The Objectively Objectionable Grammatical Pet Peeve” (January 2023). The objectionable practice in question is what Fowler calls the “sentry participle,” a participle or appositive stuck on the front of a sentence that could just as well have done without it. For example:

Yesterday on the cpplang Slack, someone asked the purpose of std::has_unique_object_representations_v<T>, and someone else pointed to an example given in Steve Dewhurst’s “Back to Basics: Class Layout” (2020). Sadly, that example is incorrect. Let’s take a look.

The other day my wife suggested the idea of KenKen “with letters.” There’s probably an idea in there related to anagrams, somehow; but the first idea that popped into my head was to use Roman numerals. Here’s a “really Latin square” for you to solve:

Previously: “LONG0751 has been found” (no spoilers), “LONG0751: Mysteries of Donovan’s map” (minor spoilers). This post contains major spoilers for LONG0751!

Here’s a weird vendor divergence recently spotted on the cpplang Slack. Consider a function template foo, where instantiating the body of foo<int> will give an error. For example: