Title: Francis' Scribbles

When I picked up the current issue of C Vu, I was surprised to say the least by the item on the inside back cover. Over its seventeen years of existence ACCU has very rarely changed its membership rates. When ACCU was first founded as CUG(UK) the cost was £10 for six issues of the newsletter. A few years latter when we had stabilised to an annual membership fee and a guaranteed number of issues of C Vu per year the cost went up to £12. Several years latter when we re-organised to two levels of membership and added a Corporate membership the costs went to £15, £25 and £80. Since then careful housekeeping and the acquisition of substantial advertising revenue has kept the costs at those levels despite going to full colour covers, professional production and so on.

Advertising revenue is fine but it does require someone with considerable expertise to bring in and hang on to advertisers. This is true for all publications. Getting advertising is hard work.

A second quiet change has been happening. The growth of ACCU over the last ten years has been almost entirely in non-UK membership. The cost of postage has steadily increased. Originally the contribution made to general administration costs by non-UK membership fees was low but positive. By that I mean that if we worked out the cost of the printing and distribution of C Vu and Overload to non-UK members it was only a little less than they were paying in membership. None of us had any concern about that because we believed in the principle that a truly international organisation should not have differential fees depending on geographical location.

With the steady increase in production and distribution costs for our periodicals, overseas membership has moved from marginally in the black to substantially in the red. Couple that with a very welcome increase in non-UK membership (over 40 countries the last time I looked) and the loss of advertisers and we can all see that a substantial readjustment of membership fees became necessary.

Now there are two things you can do to help keep ACCU membership fees stable for another decade. First you can help increase the number of members. That allows the administration overheads to be spread over more people. The second thing is to think carefully about how to bring in more advertisers. In days gone by my rule of thumb was that selling all six cover pages should pay for the professional production editing of our periodicals. Other advertising should be such that a page of advertising pays the costs of two pages of editorial content. That would mean that an issue of C Vu with 32 full pages of editorial content would be fully paid for if all the three cover pages were sold and an extra 16 pages of advertising were included. To actually achieve that you would need to pay a full time advertising manager so it will not happen. Nonetheless every little bit helps.

So what has this to do with the title of this item? Well it was seeing that change in membership fees that started a train of thought. Things are not immutable. We need to take stock from time to time and make necessary and purposeful changes. What we should not do is change for change's sake. We should always strive to understand why things are the way they are, and understand what we are trying to achieve.

I am reminded of the very first essay in Programming Pearls (Jon Bentley, 0-201-65788-0) which should be required reading for everyone who is asked questions of the form 'How do I do...' Overtly the essay is about sorting but that would be a very shallow view. The point that Jon Bentley was making is that we should be wary of answering such questions with anything other than 'Why do you want to do that?' Until we have the answer to that question, even the most erudite direct answer is unlikely to actually help.

Now go back to what I have written above and see how, I hope, I have applied that lesson to the question of membership fees. There is a lot more that I have not written, but the essence is that reactions to changes to the membership fees must be based on an understanding of what they are for and why ACCU needs more income.

If all that our Committee did was to up the fees they would be doing a poor job but you know as well as I do that they are one of the most hardworking committees of any purely voluntary organisation. Quite apart from keeping ACCU running on a day-to-day basis they are also reviewing many aspects of ACCU. In many cases these are things that have just grown out of an accumulation of small decisions that made sense at the time.

The nature of ACCU has changed slowly but surely. In the early days the Committee was almost entirely composed of enthusiasts and there was a fair sprinkling of amateurs (those for whom programming was no part of their paid work). These days the ACCU Committee is composed almost entirely of professional developers with a sprinkling of language experts.

Each year a number of people resign from membership because they have moved on from programming. Some of those have genuinely moved out of IT and no longer have any interest in software development. However for a good number this is not the case, they have simply moved up the hierarchy to jobs that do not involve expertise in use of one or more computer languages.

Now the point I want to put to you is whether ACCU should expand so that those longer-term members whose careers have developed still have a place in ACCU.

I feel the answer should be yes but I am far from certain that I know how we could achieve that. Of course there is a way in which such issues are entirely academic for me but that does not prevent me from raising the question and pondering about an answer.

One of the things that has grown by accretion is our book review system. I think it is past time that we gave it a good shaking and decided the degree to which it should change. To do this we must focus on why we review books and why we add a classification to reviews on the website.

A book review carried out by a single reviewer is always a personal statement by that reviewer. As a reviewer I can choose to recommend a book or tell you that I think you should leave it firmly on the retailer's shelf. It is very important that publishers of reviews are open to publishing second reviews that are in radical disagreement with the first. The publisher must also willingly withdraw any statement that is factually incorrect.

Now as the number of reviews grew and we started publishing them on the web we started adding a recommendation. This was intended to help people who lacked time to read all the reviews by steering them towards ones they might find worth consideration. Unfortunately, as time has gone by these recommendations have become increasingly perceived as either an ACCU one or that of the reviewer (which sometimes they were). I find that very dangerous. And it is time for change.

However my view is that in that change we need to make it much clearer that the any recommendation is that of a specific reviewer and not and ACCU one. The reviews on our website are not and never have been ACCU reviews. If we wanted to do that we would need a review panel and a consensus developed before we published a recommendation. For books that are already published we would never have the resources even if we had the will.

For now I want you to think about the issues around this one very public area of ACCU's work. Should ACCU as a body ever endorse a book? If so, how should we do it? In coming to an answer we must first understand what we are doing. We must also understand what we can reasonably deliver.

I have some very specific ideas about this which I will present in a later column.

While searching for a multi-platform IDE for my next book I came across JGrasp. This is an IDE explicitly developed for teaching purposes. The developers are a group at Auburn University. While the implementation is in Java and the original work was done for assist with teaching Java, it is multi-lingual as well as multi-platform.

It supports a considerable range of C++ compilers and has some very nice features. At the moment there are a number of flaws on the C++ side. For example, it does not currently have a simple way to give both a simple library path and enable use of third party libraries. It is fairly simple to modify the scripts to solve that problem, and in the next release that will have been done.

In the meantime, if you have a moment have a look at it from http://www.jgrasp.org/ and let me know your thoughts about it.

And while I am thinking about it, can someone explain why G++ has that horrible way of modifying file names on the command line (adding 'lib' to the start of a library name to determine the file name.)

Over the last few years there has been a terrible decimation of periodicals for software developers over the last few years. The highly specialised ones such as those for the embedded software developer have managed to hang on in their niches. Dr Dobbs' Journal has survived the general carnage but the breadth of its coverage means that for most readers only a few items are of potential interest in any single issue.

CUJ (The C/C++ Users Journal) traces its origins back to being the newsletter of the C User Group (a US based group that was founded a little before ACCU - originally called CUG(UK) though it had nothing to do with the US group). While CUG(UK) developed into the ACCU we have today, CUG became no more than the tail on the CUJ body. Our periodicals serve ACCU members whilst what is left of CUG is a small added value for CUJ subscribers. I have not seen a copy of CUJ for some time but understand that various changes have happened over the last couple of years which have culminated in Chuck Allison departing as editor (and I note that Bill Plauger is no longer listed in its editorial staff). If anyone can provide details, or better still write a review of CUJ as it is in 2004 I would be grateful.

Now those who went to Chuck's Keynote at this year's conference will know that he is heading up a new electronic publication specifically for C++. That has now gone live and you can see what is happening by visiting http://www.artima.com/cppsource/

Now from the newest to the oldest (at least I think it is). Software Practice and Experience is currently in its 34^th year of publication. Like DDJ, it covers a very broad range, unlike DDJ it is a genuinely peer reviewed 'academic' publication. Unfortunately it is extremely expensive. Through the early 90s it tended, in my opinion, to be too academic in the prose style of its contributions. This resulted in thousands of words of turgid prose whose aim seemed to be to hide great information behind text that did everything but assist in communication. Either this has greatly improved over the last few years or I have become better able to handle the academic prose style.

Here is the code again:

#include<iostream>
#include<cstdio>
using namespace std;
main() {
  int n;
  int waste;
  char name[51];
  cout << "Enter any integer number...\n";
  cin >> n;
  cout << "Enter your name...\n";
  cin >> waste; // 'gets' does not read the
                // name if this line is omitted.
  gets(name);
}

Experienced C++ programmers will immediately spot the problem; the programmer has hacked out a solution to it. The code mixes different forms of access to the standard input stream (aka, console input). After getting the value for n there will be, at a minimum (unless the programmer uses that horrible 'Ctrl Z' for Windows or 'Ctrl D' for Unix (and variants) which is, in my opinion, one of the few blots on Accelerated C++) a newline character left in the input buffer. Using any of gets(), fgets() or getline() will read that character and stop.

The hack that the programmer has come up with is to try to read a number. Now that read will succeed if the user carelessly types in a number before entering their name on the same line. Or it might fail because the next non-whitespace character read from stdin is not a digit or a plus/minus sign. However whichever happens (as long as the number isn't on the same line as the integer entered for n) the newline character terminating the previous input has been consumed.

Now either gets() or fgets() will correctly read the following whitespace terminated entry. However all versions of the C++ getline will fail unless the user actually did provide waste with a numerical value. The reason being that std::cin will now be in a fail state and so ignore all input requests.

The positive aspect of this example is that the original programmer had the sense to ask why his hack worked. However the warning is that learning to program is much more than just getting code to compile and produce the result you expect. It is essential that the programmer understands why the code works.

Comment on the following both as Java and as C++.

Last time I gave you:

Perhaps it was too tough for most of you, as I have had no responses.

Perhaps the clue needs a bit more polishing. The answer is 28 which is the second perfect number (a number which is the sum of all its proper divisors; 28 = 14 + 7 + 4 + 2 + 1). Aloud that sounds like 'twenty ate'. However the positioning of the 'sounds like' in the clue is wrong. Perhaps a better version would have been:

Taking a basic idea for a clue and honing it takes both time and experience. The latter I have but the former was lacking last time. My apologies.

Now, try this one:

When you have the answer see if you can provide either a new clue or improve my one. As an incentive I will send the author of the best clue (in my judgement) a copy of The Elements of C++ Style.