[today’s run: 3.2 miles]
A lot of my work these days involves writing and modifying programs in the language C++. Actually most of it is adding features and fixing bugs. Sometimes when I add a feature I might have to expand the overall program a significant amount. But we also have small errors to fix or small changes to the specification that we need to implement.
Speaking of specification! I am mostly working in the realm of user interface (UI) which is physically a touch screen (no keyboard or mouse). The UI people tell us what they want the screen to look like and how the interactions work. Our screen is about the size of a Kindle book reader but it is thicker and has a bit more heft to it.
So we have these specifications which are illustrations of the various permutations of the screen. And we have some written documents that include more of a written description of the underlying happenings. Every computer program has an architecture of terminology and relationships. For example an accounting system probably would have line items, invoices, balancing reports and whatnot. Our written specifications talk about messages going to and fro between this display and other parts of the machine. For example we might get a message from the gas tank somehow that tells how much gas is in the tank. And then that written description would be correlated with an illustration in the UI document. It might be my job to make it do that.
We have a pipeline for tasks for the group. When I get done with a task there are usually some waiting in the queue. When I am done I submit my changes to a system that prompts some other folks in my team to check over my work and test it out.
[I apologize if I’ve described all of this before. I don’t remember.]
Ok, so we use a library to help us particularly with screen drawing elements, things like pretty text, boxes, pull-downs, etc. This library also has things for playing audio clips/sounds, making layers of graphical elements, even ways of breaking up one program into multiple parts and interacting between the parts. The library is called Qt.
(I just say Q T, some people call it “cute” which I find kind of annoying. I don’t tell anyone that because why antagonize them for my problem. But “cute” is too cute so I just say Q T.)
The Qt way is to use things called signals and sockets, which is a form of asynchronous communication between different parts of the program. What that means is that things happen, and when those things happen you want other parts of the program to respond. So one bit will send a signal and some other bit somewhere will have a slot which is set up to receive that particular signal and the reception of the signal makes stuff happen.
This kind of program structure is good for multi-threading. A thread is the smallest type of process. I could go look it up, but I believe a thread is defined as a separate parallel processing path through the code that shares data with all of the other threads. For example a spreadsheet could have data in the cells and you could change something and it might kick off multiple threads to recalculate sections of the spreadsheet, or subsheets that aren’t currently in view, or change the graph. It’s a way of speeding things up by putting more of the CPU cores to work. Shared data, shared code, different processing path, that’s the thread.
Sockets and signals work well in a multi-threaded program. You don’t know when this event over on the left side will happen, but you register this socket on the right side to listen for that signal, and when it does happen this bit over on the right jumps into action. Left side reads numbers coming in from the gas tank and signals the value, right side receives and then changes the little drawing to look like half full (or whatever).
The Qt model works well for that. Otherwise you would have to do some message passing or some other structure. You could put everything in shared storage, like a database. Databases are not usually instigators of action, so there might be something needed to watch for this shared value to change and the signals/slots has that covered. Shared values also can get into thread troubles. You need a way to make changes to shared values that keep readers from getting intermediate data (data in the middle of a change) If your database is sophisticated it should have a facility for making changes “atomic” which means they happen all in one motion… so the data values are never in an intermediate state.
So Qt is what they chose to use and it works fine. Parts of it I really like.
The programming language C++ is supposed to be “object oriented” which was a stylish thing to do in the late 1980s. Other OO languages include Java and Smalltalk. Java was and is a commonly used language. Since the turn of the century the OO languages have slowly shifted. OO style uses heirarchies of objects. Objects are a unitized collection of data and the operations on the data. For example, each cell of the spreadsheet could be an instance of a CELL object. And you can do things to all of the CELL objects in a generic way. Pure OO you have objects that contain other objects and some object that extend other objects. A POODLE extends the type of object called DOG which extends the PET object. A PET may have a verb called feed. You could have a specific POODLE with the name floofy and then do something like floofy.feed() to say that the dog gets fed. You then could have a fish pet and say gloopy.feed() to fill his little fishy tummy. This structure of imaginary objects can get really complicated. With Qt you skip most of the object architecture. OO in general has kind of gone out of fashion; it takes a lot of up-front work on the architecture that might cause you problems later on if you were wrong. It is not so bad that you can floofy.walk() but you can’t gloopy.walk(). The problems start when you have something that is a PET but also a ROCK and you can rocky.bathe() but you can also rocky.smelt(). They call that multiple inheritance. It can get messy.
We use the packaging of data and verbs quite a lot but we don’t use the “is a”, inheritance/extension relationship very much.