Callee-destroy versus caller-destroy parameter lifetimes

I was just discussing Clang’s [[trivial_abi]] attribute with Mathias Stearn. Specifically, the fact that [[trivial_abi]] changes the Itanium ABI for trivial-ABI types so that parameters of trivial-ABI type are owned and destroyed by the callee, rather than by the caller.

Now consider two pieces of C++ code. One of them works in practice today; the other does not. Neither one is guaranteed to work. They both have implementation-defined behavior (that is, it is implementation-defined whether their behavior is undefined or not). …

Read More

[[trivially_relocatable]] in San Diego: call for reader feedback

On the morning of Wednesday 2018-11-07, my paper P1144R0 “Object relocation in terms of move plus destroy” was presented at the WG21 meeting in San Diego. It was presented in an early-morning session of SG17, the Evolution Working Group Incubator (EWGI), which is one of two “incubator” study groups newly formed for the San Diego meeting. (This means that it did not get seen by EWG.)

Read More

Puzzle: Sudoku Stories

Today I discovered a little book called Sudoku Stories (Oscar Seurat, 2014). Each page presents a little encyclopedia entry on some random topic accompanied by a sudoku puzzle whose pre-filled cells trace out a shape corresponding to the entry. For example:

Read More

C++2a idioms for library feature detection

The C++2a standard will introduce the <version> header, which contains all the “feature macros” indicating features supported by the standard library. So if you live in the year 2035 and compile for a lot of different compilers, all of which support at least the bare bones of C++2a, <version> might soon be your best friend.

Read More

The “Red Clause”

Lately I’ve been reading Samuel Hopkins Adams’ investigative journalism piece The Great American Fraud (serialized in Collier’s, 1905–1906). Adams inveighs against the scourge of “patent medicines” that were in most cases neither patented, nor medicines, but rather delivery vehicles for alcohol or worse.

Read More

Trivially Relocatable FAQ

I presented P1144 “Object relocation in terms of move plus destroy” at the SG14 working meeting on 2018-09-26. Here are three questions that came up during the Q&A and which have come up before; I thought I’d put them into a little FAQ for quick reference.

Read More

Trivially Relocatable versus Destructive Movable

I presented P1144 “Object relocation in terms of move plus destroy” at the SG14 working meeting on 2018-09-26. I was also pleasantly surprised by the number of shout-outs the idea received at CppCon in general — including in Mark Elendt’s keynote. (The specific shout-out to “std::trivially_relocatable in the pipeline” is at 42m00s. I did talk with Mark later on and point out that “in the pipeline” is an extremely generous way to describe the situation!)

Read More

Pray-Mister-Babbage problems

On two occasions I have been asked,— “Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. …

Read More

“Perfect backwarding”

Tonight at CppCon, Ezra Chung gave a lightning talk on what he called “perfect forwarding and perfect backwarding.” Perfect forwarding, as we all know, is when you receive an argument from above and pass it downward with the same value category; Ezra’s “perfect backwarding,” then, is when you receive a return value from below and pass it upward with the same value category.

Read More

Data race when catching by non-const reference

People say “always catch exceptions by const reference,” which I think is good advice. I’ve worked on at least one codebase that catches by non-const reference, presumably just because it’s shorter to type. This has never caused any problem for them in practice, as far as I know. But in theory, it’s a bad idea, because in C++ it is possible to construct a program where two different catch-blocks, executing concurrently, actually reference the exact same exception object. In that situation, any mutation to the exception object will cause a data race. The easiest way to prevent the race is to prevent mutation: to catch by const reference!

Read More