Title: Francis' Scribbles

I was sitting in a meeting room just outside Nice in March 1998 and the topic was what we should do with the Standard that we had just finished. I proclaimed that apart from anything else I would get it published through BSI for £25.

That bold statement ruffled a few feathers higher up because it was not long after that ANSI made a pre-emptive strike and provided the C++ Standard in PDF format for $18.

Getting BSI to realise that the only way it would get any real income from either the C++ Standard or the coming new C one was to use a professional publisher and obtain some royalties was immensely harder than I had naïvely expected.

Even when we had got tentative agreement other events intervened, such as having the Wiley editor handling the project be made redundant. However with the help of other ACCU members, in particular Lois Goldthwaite, we have finally completed the project for both C and C++. The cover price isn't the £25 I was aiming at but if you go to www.amazon.co.uk you will find they are offering both volumes at a discounted price of £24.47 each. That means that for an investment of under fifty pounds (including postage) those living in the UK can have two excellently bound (the pages do not turn with a will of their own) books that contain the most up-to-date versions of the C and C++ Standards (both include the latest Technical Corrigendum folded into the text). As a bonus, the C Standard also includes the current Rationale that explains the decisions that WG14 made when changing the original 1989 standard to the new 1999 one.

Those living in the US might check www.bookpool.com, which seems to give better deals on computer books than www.amazon.com.

I hope ACCU members will give serious consideration to owning their own copy (or getting their employer to do so) of either or both Standards. When thinking about it you might note that despite being in a privileged position (i.e. entitled to free electronic copies of the relevant Standard) many members of WG14 & WG21 have ordered one or more printed copies (yes, they did get a heavily discounted special offer but even so they recognised that the printed version would assist them.)

Most of us know that the C and C++ Standards allow a degree of latitude in the representation of floating point types. In addition you probably know that the two commonest radices used are two (binary) and sixteen (hexadecimal). While ten is allowed it is rarely, if ever, used.

Some of you may know that the use of radices that are not capable of exactly expressing decimal values is very problematical in some application domains. The whole financial sector is hemmed in by national legislation requiring levels of accuracy that are very difficult to achieve unless calculations are done in base ten.

Historically hardware has been based on binary (which, of course, makes octal and hexadecimal straightforward) because it was immensely easier to design and implement electronic circuits in terms of two-valued systems. However this incurs a steep penalty because providing exact decimal arithmetic requires substantial software.

For example comparing computation using a normally coded (binary) double with the equivalent computation done with an exact decimal type (provided by software) produces performance factors of between 100:1 and 1000:1. In numerically intense computations for accounting purposes those figures really hurt. Accounting packages typically spend between seventy and over ninety percent of their execution time in decimal evaluations. If that could be moved from software emulation to hardware decimal floating point units we could achieve a net performance gain by a factor of over three. This is in an industry where a performance improvement of ten percent is considered a major breakthrough.

One of the biggest players in the financial world is IBM so it is not surprising that they have both recognised the problem and come up with proposals to tackle it with specialised decimal FPUs.

That is fine, but to profit from this we need language facilities. When we look at the problem in more detail it seems that supporting such things as IEEE 754R requires more than simply moving to using a radix of 10 in our existing floating point types.

IBM recognised this and came to WG14 (C) via the BSI C Panel with a request that they (WG14) started a work project to investigate how best to support the planned new hardware. At that time I strongly recommended that WG21 (C++) were approached in the same time frame. Even though time was short, IBM were persuaded and briefed its representatives on WG21 to present the case there as well.

Both Committees were convinced that they needed to consider how best to support the coming hardware. Both Committees were initially sceptical that much needed to be done but both have been convinced that there is more to it than a first glance might suggest.

Please note that neither Committee thinks it knows the right way to use the coming hardware. Both recognise that they have work to do to build the best possible language framework on top of both the coming hardware and the already existing ISO, IEEE and ECMA standards.

It is what happened next that is quite exceptional and firmly gives the lie to those who claim that WG14 and WG21 are in some way competitors.

ISO and IEC singularly fail to provide any mechanism by which two work groups can directly cooperate on a single project yet such is the desire of the two Committees to work together on this issue that they searched around for a mechanism.

The agreement is that both WG14 and WG21 will submit identical work requests to their parent committee, SC22 and nominate the same editor. They then plan to do the actual work via a Rapporteur group. This is a mechanism that allows non-committee experts to participate freely. Each WG's Rapporteur group will meet with those from the other WG as technical experts.

It really takes highly motivated and creative programmers to come up with a solution to side step the constraints of bureaucracy. Where there is a will there is a way. And I am very happy that the will is there and do not ever let anyone get away with claiming that WG14 and WG21 cannot work together, or even do not want to. Clearly where there is shared interest they can and will.

If you want to know more about IBM's proposals, the background and existing work in the area try starting at: http://www2.hursley.ibm.com/decimal/

As if agreeing to cooperate on one major item were not enough WG14 noted that the current C++ Library Technical Report included support for a range of special maths functions (such as gamma). If C were to support these there are various issues that would have to be addressed because of the lack of overloading, default arguments etc. in C.

It was clear that the reasons for C++ including these special functions were also valid in C, but it was also clear that C should include them in a way that was entirely compatible with C++. WG14 requested through its extended liaison with WG21 that the necessary work be done between the Committees so that this part of the C++ Library TR could be paralleled by a C Library TR. Not only was this agreed but certain changes were made to the C++ TR in order to ensure that C could provide maximal compatibility.

Tom Plum, our host for the recent WG21 meeting in Hawaii, arranged a trip to the high altitude observatories. Unfortunately I had to miss it because I was suffering from a serious cold (not a good idea to go to 13500 feet in such circumstances) but a group of those who did go had lunch with some of the astronomers in order to discuss how C++ might help with their software.

Those that went tell me that it was an interesting meeting. Many members on the WG21 side had not previously met technical professionals for whom programming was a necessary part of their work whilst being entirely a chore and incidental to their main interests. These are the kind of programmer who can be forgiven for not reading books and magazines about programming. Just as many of us probably have wild misconceptions about astronomical tools (garnered from popular publications) they had wholly inaccurate views of what might be achieved through using C++. They do have real needs for high performance software and had come to believe that that meant they needed to use C rather than C++. On the other side they needed software that would work happily over the Internet and believed that Java was their principal option.

The astronomers went away with at least a sense that modern C++ might help them. WG21 went away with an understanding of how important it was to provide first class special purpose libraries that would allow such incidental programmers to use the full power of C++ without having to become expert at all the dirty detail.

Kona on the Big Island of Hawaii is a beautiful location in which to work (and I can assure you that both WG14 and WG21 members who were there worked very hard) but this particular set of meetings seems to have been productive in subtle ways that I think will become more evident in future years.

For me personally it will always be tinged with a little sadness because on the Sunday morning between the meetings as I was preparing to have a relaxing day visiting places that I have become fond of in previous visits my son rang to tell me that my mother had died. Actually for her that was good news because the last couple of years of her life have been ones of great pain both mental and physical. However losing a greatly loved parent hurts however much one is prepared for it.

My book is due out in early December so make sure you recommend it to all those friends and relatives who keep asking you to explain what it is that you do.

Please look at the following two functions that are intended to save and restore the red, green and blue intensities of a palette of 256 24-bit colours. Actually you do not need to know the gory details, all you need to know is that the first function writes some data to a file and the second is supposed to restore it. What is wrong?

void save_palette(playpen const& canvas,
                  string filename) {
  ofstream out;
  open_ofstream(out, filename);
  if(out.fail())
    throw problem("Could not open file");
  for(int i(0); i != 256; ++i) {
    HueRGB const mix(canvas.get_entry(i));
    out << int(mix.r) << " "
        << int(mix.g) << " "
        << int(mix.b) << '\n';
  }
}

void restore_palette(playpen & canvas,
                     string filename) {
  ifstream in;
  open_ifstream(in, filename);
  if(in.fail())
    throw problem("Could not open file");
  for(int i(0); i != 256; ++i) {
    canvas.set_entry(i,
    HueRGB(read<int>(in),
    read<int>(in),
    read<int>(in)));
  }
}

The following is a template function to extract a value from an input stream.

template<typename in_type>
in_type read(std::istream & in) {
  in >> temp;
  if(in.fail() and not in.eof())
    throw fgw::bad_input("Corrupted data");
  if(not in.eof())
    return temp;
  else ???
}

The problem is that there are two distinct circumstances in which the eof flag may be set. There are also other problems with the above code, such as the use of an undeclared variable.

In the first it happens as part of the process of successfully reading the last item of data. This is the case where the input stream does not include a final carriage return. Clearly in this case we must not throw an exception because the wheels have not come off yet.

The second case is the more normal one where the last entry in the input stream is followed by a carriage return. What happens is that the function tries to extract an item of data but fails and as part of the process sets the eof flag. The user cannot know this will happen (unless they write code that looks ahead which would sort of reduce the usefulness of the template.)

Typically the user wants to be able to write something such as:

while(true) {
  int value(read<int>(infile));
  // process result
  if(infile.eof())
    break;
}

We will see that we cannot quite achieve that simplicity but we can get close.

The problem case is the second of the two above. I do not want to throw an exception for a variety of reasons, not least that reaching the end of a file is not exceptional. That means that if an attempt to extract an item fails because the end of file has been reached we need to return some dummy value to give the user a chance to detect both the end of file condition and that the returned value is just a place holder rather than the last item in stream.

I want to allow users to provide the dummy value, but not require that they do. That makes me consider using a parameter with a default argument. Consider this code:

template<typename in_type>
in_type read(std::istream & in,
             in_type dummy = in_type()) {
  in_type temp;
  in >> temp;
  if(in.fail() and not in.eof())
    throw fgw::bad_input("Corrupted data");
  if(in.fail()) return dummy;
    return temp;
}

This is not very different to the original but that default argument has an added advantage in that it makes it clear that the function only works with types that are default constructible.

Notice how the last three statements progressively eliminate the special cases. If you are one of those who cannot abide multiple return statements then the code is easily fixed up to cater to your prejudices:

return in.fail() ? dummy : temp;

Now let me view this from the user's perspective. The following will work quite safely even if it might process one too many elements:

while(not infile.eof()) {
  int item(read<int>(infile));
  // process item
}

The programmer can do a better job with:

while(not infile.eof()) {
  int item(read<int>(infile));
  if(not (infile.eof() and (item == int()))) {
    // process item
  }
}

Note that the right hand operand of the and is only evaluated if the end of file flag is set. This means that, in general, the more expensive expression is only evaluated if it is needed to make the decision.

I would be interested in reader feedback on this because it is part of an ongoing process of refining a useful and safe mechanism for extracting data from input streams. I think that having such a mechanism is important because it makes C++ more accessible to novices.

Last time I set you the following little problem concerning 'Greek' style clues. Unfortunately I miscounted on my fingers and gave you the wrong number (I meant to give you 271, that is covered by 'apt', 'tap' and 'pat'). 261 only provides 'oat' and 'Tao'. Perhaps this error confused you into thinking you did not understand the problem. I hope that was the reason that I have not had any responses because otherwise it says little for the creativity of my readers. Anyway here are a couple of possible clues for 261:

And for the intended value (271):

[Based on: A-J representing 1 to 10, J-S representing 10 to 100, S-Z representing 100 to 800.]