Reenigne blog

I think that of all the features of C++, destructors are probably my favorite. They seem simple enough (code that is run when an object is destroyed, ensuring resources are cleaned up) but when you look into the consequences of that, they change the entire game and mean that C++, while it looks at first glance quite similar to C, is a very different language altogether.

RAII gets talked about a lot but the real meat of it is RRID - the destruction part.

For one thing, they mean that some things can now happen implicitly, rather than having to be explicitly coded. That's a good thing - it means the higher-level code can be terser and terser code is less likely to contain bugs. A common complaint of C programmers learning C++ for the first time is that they can't see exactly what's going on by looking at the code any more - but what they haven't yet realized is that that is a good thing.

For another thing, they make exceptions possible, with all the benefits they bring, and without the overhead, non-orthogonality and non-determinism of garbage collection.

Because destructors are not like normal functions, there are some things that you should not do with them (like throw exceptions from them). One way to think about this is that normal functions (including constructors) do "forward" work and destructors to "reverse" work (undoing things, releasing resources etc.). The reverse work should never be able to fail because that means that neither forward progress nor reverse progress can be made - it means the program is irretrievably broken and must be terminated immediately. Hacks like uncaught_exception() should not be used - if you're tempted to use it is a sign that you're trying to make forward progress in a destructor and that you should re-think your design.

Another way of writing "reverse direction" code in some languages is "finally". It's too bad that C++ doesn't have this (you either have to catch and rethrow or write a special object) - there are occasions when you want to do some one-off cleanup and don't want to have to write a whole class just to get a destructor, and the "finally" notation makes it clearer than the catch/rethrow notation. I wouldn't give up destructors for finally, though, as some languages do.

I was thinking about FPGAs recently, and that got me wondering about the possibility of designing a computer architecture that is completely homogeneous - that is, composed of a number of identical cells arranged in a square grid. Some of the cells (presumably those on the edges or even just a corner or two) would be connected to IO devices (perhaps directly, perhaps via a bus for a more general machine).

Each cell would have some kind of logic and a small amount of memory (enough to remember how it is connected to adjacent cells and to use as actual user memory).

We would like to be able to have different pieces of the machine doing different things at the same time, so cells should be independent (except where we explicitly connect it to an adjacent cell).

We also want to be able to have the hardware reconfigure itself (so while group-of-cells-A is doing something else, group-of-cells-B can be reprogramming group-of-cells-C). In order to do this, we need to make it possible for each cell to be able to address any other cell that its connected to.

If we have some string of cells connected together in a line, how do we differentiate between data sent all the way to the end of the line and programming instructions sent to a particular cell somewhere along the line? For a chip with 2ⁿ cells we need to have at least n+1 bits connecting each cell to its neighbours - n data bits (x) and one "program" bit (p). If a cell in "interconnect" mode sees an input of (p,x)==(0,x) then it passes (0,x) out the other side. If it sees (1,x>0) then it passes (1,x-1) out and if it sees (1,0) then it is reprogrammed. I guess we'd also need some additional data bits to tell the cell what mode it should be in after reprogramming. A cell with 4m input bits and m output bits has requires 2^4mm bits to completely describe its truth table and this is clearly going to be larger than m so obviously we can't program it with any arbitrary truth table in one go - we'd either have to upload it in pieces or limit the possible cell modes to some useful subset of the possible truth tables.

This is probably an incredibly inefficient way to build a computer, since for any given state a large number of the cells are likely to be acting as just interconnects or just memory and only using a tiny proportion of their capacity. But having the cells be identical might mean that doesn't matter so much if we can build a very large number of them very cheaply.

A variation on this architecture might be to have the cells arranged three-dimensionally in a cube rather than than on a flat 2D surface. Current photolithographic fabrication technologies aren't quite up to this yet (the fattest chips are only maybe 10 layers thick) but I expect that the nanoassembly and microfluidic channels for integrated cooling that will be required to make fully 3D chips aren't too far off. When that happens the chips will be so complex that we'll have to use concepts like repetition and fractal-like scale invariance to a greater extent to make their designs tractable. In other words, chips will start to look more biological - more like living tissue. Perhaps a more homogeneous computer design will come into its own in that era.

I recently came across an archive of old files that I hadn't looked at in a while, and found what I think are the first programs I ever wrote. In particular, the oldest program I can find that I'm sure I wrote all by myself (that wasn't written by a relative or typed in from a book) is dated 24th July 1988, 5:23pm. It's possible that I started it earlier than that or that other programs written at the same time predate it - the only timestamp supported by the DOS filing system was "last modified".

"More or Less" was written in Locomotive BASIC2 which ran under GEM on our Amstrad PC1512. GEM and BASIC2 (and therefore "More or Less") can still be run on a modern PC with the help of the instructions here and DOSBox (when run under Windows XP the instruction pointer seems to end up pointing to non-code data for some reason, and Vista graphics drivers don't support graphical DOS programs).

"More or Less" is a rough clone of a piece of educational software of the same name that ran on the BBC micros at school. I found a copy of the original - the copyright information says:
MLESS / More or Less
Microelectronics Education Programme
MICROPRIMER Software Pack 4
(c) CET 1982 /ISBN 0-86184-085-2
Program idea: A Straker, I Drysdale, A J Curtis
Programmed at C.E.C.C.
Editor: Bob Coates & Five Ways Software
Version 1.0 / 1 November 1982
Works with BBC Micro 32k (480Z and SPECTRUM versions also available)

The program displays two numbers and you have to say whether the left one is more than, less than or the same as the right one.

Not particularly challenging (even for 9 year olds) but I think the BBC version at least kept track of how long you took. I intended to add more features but (like so many of my programs since) I never got around to finishing it.

Another interesting feature of the BBC version was the intro/title screen. This printed "More or Less" in letters that grew and shrunk in height so that the line formed by the tops of the letters bulged in and out:

(kind of a primitive version of texture mapping I suppose). I wanted to reproduce this effect, but my programming skills were not up to it at the time. But I recall being quite proud of what I came up with instead - the title was centered, printed in a large font, double-spaced and the letters appeared one by one, each one accompanied by a beep (without a third party driver that I wouldn't come across for several years, BASIC2 was only capable of generating that one sound programmatically).

My version did have a few interesting features - it asked for the player's name and addressed him/her by name for right and wrong answers. The program maintained a table of scores in a disk file (not sorted, though, and not necessarily "high scores" - I didn't know about arrays at that point).

I'm sure I had written some other programs around the same time or earlier, but I guess I wasn't sufficiently proud of them to save them. In my last year at Goring primary school (which ended around the same time I wrote "More or Less") I also wrote some Logo programs to draw letters of the alphabet with turtle graphics. These were not particularly sophisticated (just sequences of forward and turn instructions, plus loops for the curved bits) but were probably the first actual programs I wrote. I don't have any record of them, though.