Title: Francis' Scribbles

Until your esteemed editor tells me I cannot, I am going to raise general issues that might concern you even if you were not a programmer. Programmers are intensive users of computers and many things that happen in the IT world impact on us. I have several such issues this time.

All of us to some extent suffer from spam. In addition there are other abuses of the email system that are causing increasing concern at various levels. Spam is just a nuisance and can normally be dealt with fairly simply. The reverse of spam, organizing many->one email as an attack on an individual or company by swamping their system is more serious

However sometimes the attempted cure is as bad as the disease. Some ISPs and far too many corporation sysadmins are adopting filters that simply reject all email that has originated from specific ISP mail servers. (forgive me if I do not have all the jargon correct. I think you know what I mean). Now this has a serious consequence where such blocking software uses some form of automated mechanism to determine what to block. It allows attacks on ISPs by using fraudulent headers. Once a block has been applied to email from an ISP it becomes much harder to communicate about the problem.

Somehow we, the ordinary customer, have to get those concerned to recognize that unilateral blocking is not and cannot be the solution.

The reason that I raise this now is that some time during the second week of May AT&T's postmaster decided that they were being flooded with spam from demon.co.uk and decided to block all mail from there. The effect was to cut off a large part of the UK's C++ experts from participation in the work of C++ Standards. On this occasion the intervention of Andy Koenig got communication re-instated but I have no idea for how long. Demon already have policies to deal summarily with any of their customers who provide an open mail-relay or who perpetrate spam.

I find Demon's attitude, or at least that of their employee who has been in email discussion with me on this issue, unhelpful. They state that the problem is not theirs. If they accept and forward inward email and dispatch outgoing email then it is not their concern if outward email is rejected because it comes from their mail server. Legally they are right, but commercially that is a poor response and one that will start loosing them customers. It isn't that the recipient or the recipient's agent rejects the email, the damaging aspect is the reason that is given for rejection. No individual can deal with claims that an ISP allows open mail servers. The only response I can give to that is to take my custom elsewhere. That makes it their problem.

In the week between the end of the ACCU Spring Conference and my departure to attend a fortnight of ISO Standard's meetings as head of the UK delegations to WG14 (C) and WG21 (C++) I received a letter and a couple of forms with the above heading in large letters. The documents were carefully drafted to imply that a change in the law that took effect in October 2001 required me to register with DPA at a cost of £95 + VAT. I was incensed but put the issue aside to deal with on my return.

When I returned and had cleared my desk of things needing immediate attention, I rang the number provided to try to ascertain why they thought I should register. I was bluntly told that as I used such things as company addresses to raise invoices I was using personal details (companies are legally persons) for financial gain and so was required to register. I was incorrectly told that I needed to register even if the only data I used was that for simple accounting purposes (raising invoices and paying bills). I put the issue on hold and prepared to raise the issue with my MP.

Before I got round to this I had to attend a BSI C++ Panel meeting and on the journey afterwards I raised the matter with three of my fellow panel members. I am glad I did, because one of them, John Crickett, remembered that he had seen something about this recently. When he got home he did some checking and emailed me that I should check the DPR's website. There I discovered what I should have noticed earlier, the documents in question were in fact from a company called 'The Data Protection Agency Services Ltd.' Yes those last two words were on the documents but in much reduced type size. This was a pure scam.

I feel annoyed that I was sucked in, but relieved that I was angry enough (initially with the government) so that I had not immediately responded. However I bet a lot of people did. The Oxford Trading Standards tell me that it is an ongoing problem that they are trying to put a stop to but as the phrase 'Data Protection' is not legally restricted any company can include it in its name.

As our cultures have become increasingly legalistic, justice has withered. The law never has been about right and wrong, but it is now even less so than it ever was. How do we change the balance so that our innate sense of justice is not constantly offended?

I hope you noticed that the ACCU Spring Conference hosted a two day Conference for the UK Python community. This was much more successful than we had expected, resulting in overflowing rooms and hasty rescheduling. It also resulted in ACCU being approached on the possibility of setting up a Python SIG. I do not know what further progress has been made in this area but I hope the idea does not die stillborn. I think that Python has a lot to offer C++ programmers if only as a tool to allow them to work more effectively. This is not just me, Andy Koenig emailed me that he was very pleased to see ACCU taking a supportive interest in Python. I also think that ACCU has much to offer the Python community. ACCU members are professionals and take a broad view of what it means to be a programmer. I recently was talking to a software development manager who had just told his Java people that they had no right to call themselves programmers until they could write software in more than one language. I wish more managers were as outspoken.

One of the very few negative responses to our Spring Conference came from a delegate who wrote "For practical, no interest in Microsoft C# rubbish." There were several people who commented that C# was the least interesting part of the program. There were also several who said exactly the reverse. Personally I think as long as there were alternatives that delegates had no reason to complain. I have no quarrel with those that simply said they found the C# part of the program unattractive, at least they had one fewer choice to make when C# was on. I do have a big problem with the quoted statement. C# is at least as well designed as Java, and Microsoft has followed through by getting ECMA Standards on both the language and the supporting technology. To my mind that puts it well ahead of Sun Microsystems and Java. However that is just my opinion. I do not think it is reasonable to judge C# purely on the basis that it comes from Microsoft (either positively, or, as in this case, negatively). Fortunately the overwhelming majority of ACCU members and those who attend our conferences take a more mature attitude.

I am in the throes of establishing a solid working relationship with Holiday Inns so that the administrative overheads to arranging meetings is reduced to the bare minimum. At the same time I am working on obtaining special room rates for ACCU members staying at a Holiday Inn. This is not as simple as it might be because I have to navigate the complexity of local (per hotel) control versus national and global control. For example I have a commitment from the Oxford Holiday Inn for a highly competitive rate for both Monday-Thursday booking and Friday-Sunday ones as long as these are made via me as ACCU agent/contact. I am pretty sure those rates would hold up elsewhere but my local contact cannot guarantee that.

I have been doing this work is to ensure that we have much better facilities for future ACCU Conferences and for the ISO meetings the UK is hosting next Spring. However there are spin-offs and I want us to develop these because I believe they will prove to be to the advantage of many members.

I was sitting beside Bjarne Stroustrup during the recent WG21 meeting and we were both answering our email. Bjarne asked me to have a look at one of his. It was from a complete novice asking him for help with some code that did not work. The code was something like:

int main (){
  int i = 5;
  int j =6;
  int k;
  k = average(int i, int j);
  cout << k << endl;
  return 0;
}

It wasn't exactly that but the problem was exactly that bizarre attempt to call a function. This was only one of several such emails that Bjarne receives every day. I am amazed at the way that he calmly does his best to respond helpfully.

Now there are a couple of points here. The first thing that springs to mind is what have we done educationally to create a generation who think nothing of emailing someone like Bjarne with problems they are having in their initial learning of C++? It seems that we have brought up a generation who have no sense of finding an appropriate source for help. Did the author of that email stop for one moment to think whether he should be emailing BS? How would he have felt if Bjarne had simply ignored him? Or emailed him back with a standard 'Sorry, I cannot help.'?

The next question that springs to mind is how we can be writing such poor introductions to programming that novices in their thousands are making such mistakes. I repeatedly see almost inconceivably stupid errors in student code. These are not subtle issues of undefined behaviour but clearly the result of not having the slightest idea as to how a computing language works.

We desperately need better books, better informed instructors and better designed courses. This is not just a C++ issue, it is a general issue with learning to program. Some languages mask the fundamental weakness of the user. That is much more dangerous because they write code that compiles and executes but is just riddled with misunderstandings.

The educational system (and that should include education in the home by parents) must address the twin problems of poorly informed instructors and inappropriate requests for help. Yes, it is great that I can get expert help when I need it, but I should have some idea of the value of the time of those to whom I address my questions. Too often questions are addressed to outsiders because the instructor who is paid to do the job refuses to help because s/he is too busy.

Look at the following code fragment and see if you can spot the problem:

template <typename charT>
charT * init(){
 return "abcdefghijklmnopqrstuvwxyz"
}
int main(){
  cout << init<wchar_t>();
}

Now this is a very simple instance of a real problem. We do not have a syntax to deal with the type of a literal in a generic way. Casts do not help us because there is no general way to change the type of a literal via a cast. This problem looks as if it is going to get worse. Both C and C++ have been asked to consider ways to give better support to internationalisation. In particular we have been asked to give direct support to more character types.

The problem with string literals is just the most visible one. We need to consider literals in general. Once we create a set of types to support measurement units - length, area, time etc. - we have many potential literals that are not interconvertible via casts. 'How should we provide generic literals?'

Until recently we have muddled along but answering that question is beginning to be important. The growth of generic programming requires us to look at ways of extending ideas. What ideas do you have for supporting generic programming with character type literals. A good solution should extend to other literals.

When thinking about this you might look at C99's compound literals.

#include <iostream>
struct ex {
public:
  int a;
  void func1(){ a = 42; }
  void func2(){ 
    int b = 27, 
    a = b + 1;
  }
};
int main(){
  ex x;
  x.func1();
  x.func2();
  std::cout << "a = " << x.a;
}

I hope you quickly spotted the comma mistyped for a semicolon. It is harder to spot on a screen than on paper. I had hoped to get a flood of email suggesting other places where typos silently change the meaning of code.

Here is another example:

switch(i){
  case1: return 1;
  case2: return 2;
  default: return 3;
}

When you spot the problem see what other cases you can think of and email them to me at <francis@robinton.demon.co.uk>.

My dictionary defines percentile as "the value below which fall a specified percentage of a large number of statistical units (e.g. scores in an examination)". The quartiles, lower and upper, are the 25th and 75th percentile. The median is the 50th percentile. For the latter, statistics has special rules for small samples where it is often necessary to select a representative value that is not a value from the sample.

Now look at the following code for computing a percentile in the form of a supposedly STL conformant algorithm.

template<class RandomIterator, class ValueType>
ValueType percentile(
  RandomIterator start,
  RandomIterator end,
  ValueType percent){
  typedef typename 
    std::iterator_traits<RandomIterator>::
      difference_type DifferenceType;
  DifferenceType n=end-start;
  ValueType rank=(n+1)*percent/100;
  DifferenceType
  intRank=static_cast<DifferenceType>(rank);
  ValueType fraction=rank-intRank;
  RandomIterator pos=start+intRank;
  ValueType result;
  result = *(pos-1) * (1.0-fraction) 
              +*pos * fraction;
  return result;
} 

What is the fundamental flaw? Let me help you:

int main(){
  int array[10] = {0,1,2,3,4,5,6,7,8,9};
  cout << percentile(array, array+10, 25);
  cout << percentile(array, array+10, 25.0);
  return 0;
}

Now do you see the problem?