Title: Francis' Scribbles

Several years ago Gary Lancaster implemented my Playpen library. The implementation worked well and did exactly what I wanted. We fixed a couple of bugs and added a bit to it. One day I added my own default palette, which I implemented by with a function. The obvious place to call this was from within the constructor for playpen. At that time, everything seemed to continue to work.

Then I noticed that on some machines the screen incorrectly updated when a program first constructed a playpen instance. It was not a big problem and seemed relatively harmless. I mentioned it to Gary but he could not see a cause and assumed that it must be something I had tweaked. At that time, I had forgotten that I had added a function call to the constructor. I left it and simply warned users that there was a harmless bug lurking in the initialisation of a playpen window.

A couple of months ago I was running a quick test and happened to write:

int main(){
  playpen paper;
}

In other words a bare minimum program using a playpen to which I intended to add some more test code.

To my surprise, the computer seemed to lock up. After about a minute it recovered and displayed an error message about a misbehaving application.

This is no longer a matter that could be ignored. I experimented a bit to discover what I had to do to avoid this lock-up. In the end I discovered that doing almost anything that stopped the program from closing immediately solved the lock-up problem.

I still did not understand the problem but I could see a simple solution, insert a call to a wait function in the constructor of playpen. [It was then that I realised that I had altered Gary's code by adding the call to the function that provided my default palette.]

Now, that fixed the other problem as well, the screen updated correctly when a program created a playpen Window.

I reported my experience and fix to Gary. Now that gave him enough of a clue to really fix the problem, which was in the original code.

You may be wondering what this has to do with your code. My playpen type relies on using multi-threading. Effectively it implements all the special simple GUI functionality as a distinct thread. The underlying problem was that programs were returning from constructing a graphics window too quickly, before Windows had finished.

This only shows up on modern fast hardware, where the CPU speed is high enough to beat some other process.

This is a good example of the problems of multi-threading. You cannot check your code is correct by testing (actually, you never can do that). Your code may work perfectly for years and then start to fail occasionally. You are certain that the code is OK because it has worked for so long and assumes that the problem is somewhere else. However increased hardware performance begins to make a real problem manifest.

By hindsight, I can see how the symptoms should have pointed me to the cause. The added function in the constructor was trying to update the palette definition while the Playpen window as still being constructed. However, had I tested a truly minimal program much earlier I would have got a much better clue, because trying to destroy a window before it has finished being created is sure to provide a recognizable symptom.

Never ignore little irritants, and test code incrementally starting with the simplest program you can write. Even a little extra may hide a real problem.

I would be very happy to hear your comments on this and other aspects of problems revealed by higher performance hardware.

Consider:

class x;
class xyz {
public:
  xyz();
  ~xyz();
  static int const elements(100);
// rest of interface
private:
  x * pointers[elements];
};

xyz::xyz(){
  for(int i(0); i != elements; ++i){
    pointers[i] = 0;
  }
}
  
xyz::~xyz(){
  for(int i(0); i != elements; ++i){
    delete pointers[i];
  }
}

Is there a better way to implement the constructor? Of course there is, and I know some of you know it but do you?

Let us have a look at the code before dealing with the problem.

The first point is that it looks as if the design intends that xyz instances own the items pointed to by the elements of pointers. If that is the case, why did I use an array of raw pointers? In addition, why did I use a fixed size array? That seems to make very little sense.

Without some idea as to what xyz is supposed to do (and the name is not exactly helpful), it is hard to see why I did not use something such as std::vector<x> or std::deque<x>. However consider the case where x is not a copy constructable, nor copy assignable type. If it also lacks a default constructor, we do not have many options left.

While testing the code I got a rude shock. First, this is what I was looking for:

xyz::xyz(): pointers() {};

While we cannot explicitly initialise an array, we can force default initialisation. In general, that gains us nothing, because that would happen anyway. The default action for the fundamental types is to do nothing; we can force zero initialisation with the above syntax.

Now to the rude shock:

static int const elements(100);

is ill-formed. The compiler considers it an attempt to declare a static member function and requires that an in class initialisation be written as:

static int const elements = 100;

Well the problem is that I have run out of a ready supply of little coding surprises and problems. It is time that you got involved. Please send in at least one coding surprise. If you do not have any then I guess you do not actually do much programming.

The surprise can be in any of the programming languages that are used regularly for application programming (C, C++, C#, Java, Python etc.)

Neil Horlock sent in this clue for last issues number (471, which is 20 more than 451 which was the title of a Ray Bradbury novel about a post catastrophe world where books were burned as evil.) The first part of my clue references the issue of C Vu in which it appeared (17.4)

Roundabout a maximum break, a thousand less than the number of the last caller.

I like his idea of using 'roundabout' to clue rotating the digits, however I think the second part of the clue could do with a bit more polish. Anyone like to propose improved wording based on the same idea (for those from elsewhere in the World, 1471 is the number for recovering the number of the last person who called you.)

This issue's clue

One for love too? Sounds like the right day for it!

Provide your clue for the solution to my clue. No prizes, just a warm fuzzy feeling of seeing your name in the next issue.