I didn’t get a good night’s sleep last night and felt pretty wiped out most of the day. I spent a little time in the Evolution Working Group (EWG), the subgroup that considers changes to the core language. All I remember is something called a “pipeline operator” which would inject arguments into following function calls. I couldn’t figure out what it was good for or why anyone would want it.
Mostly I rested up for an evening session of the numerics study group where we continued the discussion of floating point rounding that slopped over from the evening session on Tuesday. It turns out that there are quite a few cases where the behavior is not at all intuitive.
The last thing on the agenda was a paper of mine. About a decade ago or so, I had in mind a database access library in C++ that would be the rough moral equivalent of the java.sql.stuff; but I soon had some medical issues and couldn’t pursue it, and so nothing ever came of it.
One thing I needed, and implemented, was a C++ type that could give me a round trip to and from SQL’s NUMERIC and DECIMAL types which are fixed point decimals. A few years ago, the numerics folks were thinking about publishing a numbers TS. The rational number in §7 of that paper was my work; and I thought that my “big decimal” type was a kind of number, too, and so maybe a more generally useful version of it (written against C++23, has NaNs and infinities, etc.) could also go into the TS. It turns out that there’s not much interest in that any more, so I won’t be pursuing that any further. I think that was the right decision since my target audience is good old “business data processing” which isn’t really the market for C++.
I spent today in EWG where it was “safety Friday”. We spent the morning talking about various ways to mitigate the problem of uninitialized local variables on a function’s call stack. There seems to be consensus for the rule that local variables without explicit initializers should be zero-initialized (like globals are), but it turns out that there are corner cases where that could change the meaning of some code, and static analysis tools would no longer be able to flag the potential bug. We’ll need to think about this some more.
Just before lunch, we took the customary group photo
. As I write this, it’s not online yet; but I’ll embed it when it is. I’ll be which is the bottom picture among these three. I’m the old fart on the right of the first row who’s sitting on his walker wearing a St. Louis Cardinals baseball cap and an N95 mask (because COVID isn’t over yet).
After lunch, we talked about “type and resource safety”. From the paper by Bjarne Stroustrup:
- every object is accessed according to the type with which it was defined
- every object is properly constructed and destroyed
- every pointer either points to a valid object or is the nullptr
- every reference through a pointer is not through the nullptr
- every access through a subscripted pointer is in-range
Those are informal rules that C++ coders have always been expected to follow, but it’s not really possible for static analysis tools to enforce them completely. There seems to be a strong consensus for some kind of framework that would improve the situation.
Tomorrow morning will be a plenary session where we take formal votes. That should end by noon, probably before; and then I’ll be on my way back to King Street Station where I’ll board Amtrak’s Empire Builder for the first leg home.