Elaborate solution to a very minor pain-point

Over the last few years I've repeatedly encountered an annoyance in my work projects. It's not a practical problem, you understand, merely a stylistic one. I mean, when the issue rears it's ugly head I pause, curse, write the code that works just fine but offends my sense of modern C++ idiom, and move on.

It's just that the issue lives rent-free in my head.

So here's the set up: I've spent the last six years upgrading my C++ skills to the "modern" era which means, amongst other things, preferring ranged for loops and routines from the algorithms header to explicit loops using indices, pointers or even iterators.¹ Only my code has to interact with libraries and plugins written in C or exposing C-centric APIs, and those interactions often involve linked-lists. Which you can't put into ranged for loops or algorithms.

So, in my copious spare time, I set out to write a set of iterator templates that you can bolt-on to an arbitrary C linked list to support using modern C++ idioms with the list. That project is now approaching minimum-viable-product levels of completness, though there is a lot left to do.

---

¹ That kind of preference is, of course, not absolute. Sometimes the old, explicit loops have some over-arching advantage and you use them without guilt.

ODR? Fuggedaboutit!

I was hacking together a thin patch at work today. Tyring to get the logging calls from a library to play nice with the rather hacky logging infrastructure of a legacy project we maintain. Basic translation worked fine, build support took a couple of tries but seemed to be coming together, but then there was the matter of Level enum and getting string representations for the values ... so I shoved a copy of the original enum and a definition of levelText(Level level) into the header.

Yeah, the definition. In the header. I should've know better being, as I allege I am, a big-boy programmer. Well, nature took it's course and the compiler complained: I was violating the One-Definition Rule (oh, holy of holies!) on a massive scale.

But I was ready to go to lunch and I didn't want to deal with hard problems like where in the project tree to put the source file that ought to hold the implementation and how to add it to the build system and so on. It was at this point that some rebel-without-a-cause, burn-it-all-down inner-self threw up a suggestion: why not try something like:

template <int=0>
std::string levelText(Level level) 
{ 
    /*...*/ 
}

I mean, what could it hurt?

Rhetorical question, of course, but let's list some of the failing of this cutesy little trick (which compiles):

Hacky, non-idiomatic, confusing

Any C++ prgrammer who sees a template declaration will expect you to do something with the template parameter, which we don't. Time will be spent look for the use and trying to suss out what the paramter might mean. Worse, if they're experienced they'll notice that it's a non-type parameter and be expecting some kind of clever (read tricky) metaprogramming, which there isn't.

Contibutes to slow build times

Evey template read takes a little more time and little more working set. So does every template instantiated. I menetioned that this is a legacy project, right? It already takes 12-15 minutes to build on a fast hexacore machine with lots of memory.

Contributes to bloated binaries

Every template instantiation creates a separate bit of code. We're writing that function for every source file that includes the header.

Once I'm fueled back up I can go back to the office and do it right. But now I know a new stupid C++ trick. Yeah!

Color me impressed with up-to-date LLMs

I only recently started playing around with LLMs, and I started with somewhat dated models.¹ Yesterday I signed up for ChatGPT and I can see why some former sceptics have gone fully bought in. The 4o model is impressive.

My main investigative tool was to pick things that I know something about, and ask the model a question from those fields neither trivial nor really hard but requiring some nuance. I tried to select ideas with a range of popularity because I believe that the volume of writing on a subject may influce the "skill" the model exhibits. My subjects so far:

1. Discuss the Epistemological implications of Godel's incompleteness theorem.
2. Summarize Freemon Dyson's "Time Without End" paper. (If the model did well on that I followed up with a question on which of the papers conclusions had been overcome by more recent developments in cosmology.)
3. Summarize Lamb's "Anti Photon" opinion piece.
4. Discuss the similarities and differences between the movies Ghost Dog and Leon: The Professional.
5. Explain the continued strong culture of short form composition in speculative genre fiction as compared to general fiction
6. Differences between classical and modern guitar
7. Prepare a packing list for a lightweight wilderness survival kit to carry on my day hikes in the desert southwest.

My highly unscientific observation suggest that items 1, 6, and 7 are the more popular topics and should provide mode source material for the models. The movies question (4) is weird: each movie has been extensively discussed so there is a lot of source material for each movie, but I'm not sure how much human generated comparison text is out there. Then I would rank 2 and 5 a more common than 3.

I didn't get any major factual errors from ChatGPT4o. I's main fault was that much of the writing was bland and characterless on all responses. Of course, the desireablity of "character" is context dependent: an encyclopedia or other raw factual source should be pretty neutral and that's what most of the responses sound like. ALso I didn't do any prompt engineering to elicit character: I just gave the model the question and let it go.

I do have two speific comments on ChatGPT's responses. First, it's interpretation of Lamb's paper if different enough from mine that I wasn't particularly happy with it, but I wouldn't be surprised to learn that other trained and capable physicists subscribed to that interpretation. Second, the answers it gave for the movies really sounded like they were drawn almost entirely from reviews for each film in isolation:² Ghost dog this; Leon that. Over and over again.

---

¹ My initial goal was to investigate the possiblity of using a LLM as a purely local coding assistant (that effort continues). At work our security guidelines imply that no internal code or design details should be release to the wider world or sent over an unsecured internet connection. Obviously just using CoPilot from VS Code is out. But I started this investigaction on a personal machine to find out if the tooling would meet requirements before going in search of management buy-in. Alas, my "best" machine is totaly unsuited for even late 3rd gen models. I can run models up to about 1 billion parameters smoothly and easily. A 7B parameter model (zephyr) is too slow for use in a work-flow (seconds-per-word), though it's fast enough to learn about the models. I have put a 22B parameter model on the machine, but it runs at minutes-per-word.

² Indeed that observation is what prompted my comments above.

Goto is flow control!

I'm reading The Legacy Code Programmer's Toolbox: Preactical Skills for Developers Working with Legacy Code by Nathan Boccara. I'm not far enough in to have a settled opinion of the book, but I think I'm far enough along to describe it a "promising" at least.

Anyway, I'm in the first section of the book where he talks about understanding code you've just encountered. And I've already hit my second "Well, why didn't I think of that?" moment¹ where he suggests filtering functions to only display the flow control as a way of getting to know them. Fantastic idea and I feel like a dunce for leaving that option on the table for years, but I have a bone to pick with his implementation in the example he provides.

His example works on a piece of C++ code from an open source project, and he filters for

• if
• else
• for
• while
• do
• switch
• case
• try
• catch

which probably seems like a good list at first glance, but the function the very first flow control token in the example function is a label! And yeah, that means there is a goto further down.

Now, I almost never use goto, and when I do it's usually to jump to some clean-up or post-processing operation from nested scope. This one jumps beck outside a loop to do some re-initialization. Who knows if that is justified. Maybe it spares some extra nesting or multiple condition variables or something.

Whatever, I just think we ought to include goto and labels as part of the set "flow control" to filter on. And the same can be said for break, continue, and return.

Now maybe the author has a reason for the omission and just didn't tell us, and I'm guessing it makes little difference to the utility of the procedure, but I just had to get it off my chest. We now return you to your regularly scheduled life.

---

¹ Thanks, Nathan!

<

UPOL

We're on vacation this week. Out on the east coast to visit some of my wife relatives. And there is, of course, a rental vehicle involved. Now we take several short trips a year (to visit medical specialists, mostly), so we cycle through various rental options which is always nice in the sense of getting to know what kinds of mid-price car choices are out there but we usually only have them for a couple of days at a time. So we don't usually both trying to figure out the car's console.

But this time is different for a couple reason.

First because we're staying a bit over a week, and second because there is absolutely no place to prop a phone running nav where the driver can actually see it.

So we've got a phone synched to the thing and can display nav data. Yeah.

Unless, that is, you want to change the AC settings. Or mess with the audio. Or someone sends you a text. Or a myriad other things that might happen. Because the designers of this thing have moved very nearly everything that used to have a button or switch onto that single center panel and let each and every function take over the whole display whenever they are active.

I have christened it the Universal Panel Of Lose.

Now, it could be worse. I known some Tesla owners, and Muskmobile is trying to remove the stems from the steering column in favor of a cleaner look.

And I'm not against manufactures trying to improve the user interface of cars. There is no reason to think that the layout we're used to is ideal. Not even for the central controls, but especially for the lots of little auxiliary things that have accreted over the decades. Even in my life time I've gotten to watch the interface for cruise control appears in a variety of clunky states and improve by little increments until now I see one of two pattern that each works pretty well. Good job, guys. Much appreciated.

But it is painfully clear that the testers of the UPOL (which I known has infested multiple major brands all up and down the price spectrum) never actually took it for a test drive on a route they didn't know. Never needed to use the nav even while they tried to communicate with the people they were suppose to be meeting at a new-to-them destination. Basically never really ate their own dog-food.

It's a Singleton for life-cycle management, maybe?

Global state has it's well known costs, so avoiding it where reasonable is a thing. Great. But sometime you might feel you need some. Then what? This article is to record some of my thoughts about the Singelton pattern in C++

Avoid singletons —C++ Core Guidelines

Which Singelton is easy

A lot of Singelton implementations are not thread safe, and/or hard to get right. The Meyer Singelton is surprisingly simple and inherits thread-safety from guarantees made by the C++-11 standard.

When to consider a singleton

Programs can need data and they can need behaviors. You might want (or think you want) either with global scope,¹ but a Singelton class doesn't offer anything over a simple global variable for plain data. Nor does it offer anything over a simple free-function unless you want some persistent state attached to more than one function together.² Either of these is simple on their own, it's only when you need the combination, behavior working on global data that Singletons offer any advantage over simple global data or free functions. So when we look at alternatives, we should be thinking about the combination.

Alternatives

Simple global data. Suffers from the static initialization order fiasco. More than a few sources suggest that an suitable alternative is to use a namespaces and just write free code. This isn't Java and things don't have to be objects.

Interestingly the Core Guidelines suggest using the same static local variable idea exploited in the Meyers singleton implementation without the object context which does not enfore the single nature, but does give you a centralized access point for a particular instance of the data.

Object Lifecycle

But here's the thing: in C++, objects are about lifecycle. They have a defined lifetime and we are guaranteed that their constructors are called at the beginning and their destructors at the end. That's how scope bounded resource management works, afterall.

---

¹ Indeed, in the usual C++ model, almost all behavior is nominally available at global scope.

² We'll talk about peristent state attached to a single function along the way.

If incompentence seems unlikely may I assume malice?

I've mentioned before that I generally keep my project source directories at work in a place where there are accessibly from the host (Windows) operating system, my msys working environment, and my WSL (linux) instances.¹ Some IT trouble recently has seem me migrate off my usual work machine onto a loaner and now back to the (freshly re-imaged) original. Which has meant re-building my working environments a couple of times.

Now, with one thing and another my re-imaged machine came back to me without a stand-alone X11 server,² so I though "Now'd be a good time to see if WSL2 really is better than WSL1; what with the wslg display adapter meaning that WSL2 doesn't need X11." Anyone familiar with this domain will know that WSL2 has been a thing for quite a while now, but the combination of (a) inertia and (b) reports that access to the host-filesystem access was slow on 2 had kept me from moving forward.

Anyway, I tried it today.

The virtual machine actual runs noticably faster which is nice, but "slow" doesn't even begin to describe the productivity bottle-neck that is access to the host filesystem. Holy deity-figure-on-a-pogo-stick, Batman! This performs like something offered as a minimum viable product from a failing startup run by kids who really should have stayed in school. A sloth dying in a tarpit moves faster than a cmake configure over that channel. I was longing for the heady days of running autoconf on a pentium. I had time to muse about the bandwidth of a stationwagon full of tapes as delivered by continental drift.

I'm following a colleague's lead and keeping a separate source tree for the WSL image and using rsync-spawned-by-cron to keep them tracking one-another.³

And now we get around to the question of incompetence versus malice. The famous adage tells us to set our Baysean prior in favor of "Incompetence", but this is a Microsoft product on it's second version number. Incompetence simply isn't what I would expect. The usual excuses just ring hollow: the people who put this together are not beginners, they had access to as much deep technical support as they needed, and they had a v1 product out in the world doing well so there wasn't a live-or-die deadline to meet.

On the other hand, Microsoft has more than a little history of trying to leverage their market share to try to kill inconvenient competitors.

---

¹ For that matter before some "security" upgrades broke all the non-Microsoft virtualization tools on Windows (VirtualBox we hardly knew 'ya), I would use those same files from my virtual machines, too.

² Probably an oversight on my part as I don't recall saying that I needed one.

³ The thing is that parts of the host filesystem (includind the bit where I keep the source trees) is auto-backed up by IT, a feature that's very handy for the biggest part of your daily work, eh?