Little Surprises #9: too helpful edition

In Qt5, this #include <QString> #include <algorithm> #include <vector> int main() { std::vector<int> v{0, 1, 1, 2, 3, 5, 8}; QString qs("target"); // Search the vector for the string std::find(v.begin(), v.end(), qs); } will build (compile and link). There are very few circumstances where you mean what it will actually do (in this case it's a very expensive no-op), but it is valid code.

This works because of a chain of "helpful" features:

• You can construct a QChar from an int: QChar(int rc) noexcept
.
• There is a equality test between QChar and QString: bool operator==(QChar lhs, const QString &rhs) noexcept
.
• The find template uses operator== between the contents of the vector and the target.

Each of the behaviors is desireable in isolation, so we don't want to remove any of these options entirely. What causes the surprise is the implicit nature of the type conversion.¹ Core guidelines C46 and C164 discuss the uses of explicit annotation to prevent this kind of thing.

BTW: the above code will not compile in QT6 which is a small but significant improvement.

---

¹ Shout out to all the strong typing fans out there.

When I grow up I want to be...

... organized, detail-oriented, and thorough.

I imagine that will be happening ::checks watch:: any day now. Right? Right?!?

Dates are important

If you're putting a technical article on the web please, please make sure it has an easy to find date of production assocaiated with it. Seriously, technical stuff changes and sometimes changes fast. I need to know if your advice is a few years old because that might be enough to make it comprehensively wrong.

That is all.

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!

<