Title: Francis' Scribbles

Recently there was a long thread about the issue of whether we should use more than one return statement in a function. I think the most important thing is that we should try to understand the issues.

It is easy to say 'functions should have at most one return statement'. Actually if they are truly functions they need at least one return statement because the correct computer science term for something that does not return something is 'procedure'. But let me put that to one side and focus on the concept of a function in the context of C and C++.

There is certainly a correlation between bugs and multiple returns. Functions with more than one return have statistically more bugs. However there is a similar correlation between bugs and number of statements in a function. Functions with many statements tend to have more bugs than those with only a few statements. Finally there is a correlation between number of statements and number of returns; functions with many statements also tend to have multiple returns.

What I am suggesting is that the fault may not lie with multiple returns but with writing complicated code. We should avoid writing code that conceptually has multiple points of return even if we hide that by introducing extra variables or structures. The problem lies not with the multiple returns but with code whose design has more than one logical exit point.

But sometimes an algorithm has logically more than a single exit point. In such cases jumping through hoops to hide this feature breaks what I consider to be the prime directive for programming: 'Code should be a clear expression of the solution of a problem.'

There is a second programming directive 'Stop when you know the answer.' Let me give a couple of examples. The first is admittedly contrived but only to the extent that I want some simple code to illustrate a general principle.

bool contains
    (vector<vector> > const & array,
     int value) {
  int const rows(array.size());
  int const columns(array[0].size());
  for(int row(0); row != rows; ++row) {
    for(int col(0); col != columns; ++col) {
      if(array[row][col] == value) {
        return true;
      }
    }
  }
  return false;
}

bool will_be_alive(life_universe const & data,
                   int i, int j) {
  int const diagonal_neighbours(
      data[i-1][j-1] + data[i-1][j+1] +
      data[i+1][j-1] + data[i+1][j+1]);
  int const orthogonal_neighbours(
      data[i-1][j]
      + data[i][j-1] + data[i][j+1] +
      data[i+1][j]);
  int const live_neighbours
      (diagonal_neighbours
      + orthogonal_neighbours);
  if(live_neighbours == 3) return true;
  if(live_neighbours == 2) return data[i][j];
  return false;
}

return(live_neighbours == 3) ? true
: (live_neighbours == 2) ? data[i][j]
: false;

bool wba(vector<bitset<512> > const & d,
           int x, int y) {
  int const nd(d[x-1][y-1] + d[x-1][y+1] +
               d[x+1][y-1] + d[x+1][y+1]);
  int const no(d[x-1][y] + d[x][y-1] +
               d[x][y+1] + d[x+1][y]);
  int const l(nd+no);
  if(l == 3) return true;
  if(l == 2) return d[x][y];
  return false;
}

bool will_be_alive(
life_universe const & data,
                int i, int j) {
  int neighbours(-data[i][j]);
  for(x(i-1); x < i+2; ++x) {
    for(y(j-1); y < j+2 ++y) {
      neighbours += data[x][y];
    }
  }
  return(neighbours == 3) ? true
  : (neighbours == 2) ? data[i][j]
  : false;
}

One of the by-products of writing a book is to discover how helpful people can be. Of course I will be giving full credit to the main players in the book's acknowledgements section but as the printed copy won't be around till early December and its target readership has little if any overlap with the membership of ACCU I thought that I should take time out to express my gratitude to several people who have provided a lot of added value.

Because he is a fellow author, and most particularly because one of his books might be considered a competitor (Teach Yourself C++ 7ed) I have to give pride of place to Al Stevens, a well known columnist for Dr Dobbs Journal.

Not only has he made his beginners IDE (Quincy) available to all including rival authors but he also takes the trouble to maintain it and try to address any problems with it that are raised by its users. Giving a product away is one thing but adding in support is another. Both should be appreciated.

Then I emailed him to enquire about his recommendations for providing an install mechanism for a CD. Straight away he responded saying that I was welcome to use the source code provided on the CD that comes with his book. That source code provides a simple little installer and uninstaller that is exactly what computer tyros need. Al is clearly that exceptional author who tries to meet the needs of his readers. I may not agree with all that he writes and my book takes a very different tack from his but my life and the lives of my readers will have been made much easier by his generosity.

Then there is all the work that Garry Lancaster has contributed in refining the original Playpen concept and implementing it so effectively. Again, without Garry's work my book would be a much poorer product. When we have checked that there are no hidden surprises I will arrange for my Playpen Library to go on our website where it will be free for anyone to use. I think it will be useful to any novice who wants to experiment with graphics, a mouse and direct access to a keyboard. For the time being they will be restricted to MS Windows OSs.

However, as soon as I have the time to test it out I have an X Window/Posix version of Playpen, which should considerably extend the portability of Playpen based code. Jean-Marc Bourguet has done that work.

Then there is a little article written by James Holland about a flood-fill algorithm he originally used in Pascal. The algorithm dates from 1988, so that explains why I missed it as all my graphics algorithms come from earlier times. I hope the Editor gets to publish that article because I have a response lined up generalising James' contribution to work in full colour.

int foo(bool read_all) {
  if(read_all) {
    string line;
    getline(cin, line);
    return atoi(line); }
  else {
    int i;
    cin >> i;
    return i; }
}

There are quite a few things wrong with the above function definition. Assume that all the appropriate headers have been included, what particular feature of C++ input makes it completely unusable?

int foo(int i) {return ++i;}
int bar(int i) {return i;}
int main() {
  int i(21);
  cout << (foo(i) + bar(i++));
}

That one gives us a straightforward case of undefined behaviour because the call to foo() reads the value of i for no other purpose than because it needs the value. On the other hand the call of bar(i++) both reads and writes i. The Standard very definitely states that such mixture of uses (a plain read and a distinct write) without an unavoidable sequence point results in undefined behaviour. Note that the rules change if i is a user defined type. That means that it can matter if a template such as std::vector<> uses a plain pointer as an iterator or not. For example:

std::vector<int> vec(10);
std::vector<int>::iterator i = vec.begin();
std::cout << *i + *i++;

may or may not have undefined behaviour. If std::vector<int>::iterator is a user defined type the above simply has unspecified behaviour (either of the two sub expressions can be evaluated first. But if plain pointers are used then the result is undefined behaviour.

int fooref(int &) {return ++i;}
int barref(int const &) {return i;}
int main() {
  int i(21);
  cout << (fooref(i) + barref(i++));
}

Notice the difference, the fooref(i) does not need to evaluate (read) i, it just binds the parameter to the argument. The internal increment is fine because it is protected by the sequence points after the evaluation of the arguments and before the return. barref(i++) binds an rvalue (so it reads i) to the int const & parameter. As the only unprotected read of i is for the purpose of determining what should be written by the post increment we no longer have undefined behaviour. I think that if you check it carefully you will also discover that the result is still unspecified because the result depends on which function is evaluated first.

This time there were several offers of solutions. Perhaps the older readers remember playing with their electronic calculators with seven segment displays. For the younger readers there was a fad in the seventies for making up calculations that resulted in displays that could be read like words (sometimes upside down). In case you did not work it out, the solution to It looks like a call for help. is 505.

There are many potential numbers that can be clued this way (upside down is more productive) and we sometimes have to tolerate mixtures of upper and lower case letters. So we have 'Almost a capital example of what might be sold on an Antipodean shore.' in six digits is 577345. You need to check how a seven-segment display handles 4 to understand that one.

I am sending (when he jogs my memory) a copy of the C++ Pocket Reference to Bob Adler whose response had the added value of referring to his days in the dojo.

Now if I gave you 'That foolish day' as a clue you might quite reasonably think of 1st April. But what might 'An English programmer gets pieces of eight for the day of fools.' give as a two digit number? As an added clue an American would get a three-digit answer.

Again I will give a small prize to someone who supplies the English answer.