Title: Francis' Scribbles

A couple of people (with regret, one of them a long-term ACCU member) having been gossiping about a confidential Standard's issue that concerns Lois Goldthwaite and myself. I do not intend to add more fuel to an already blazing pyre by going into details here.

However, "do not repeat rumours that can prejudice another professional" is a guideline that should be automatic among professionals. To that, I would add that anyone who ignores such a guideline is behaving unprofessionally. Of course, we all have a tendency to gossip but we should make an effort to avoid doing so when people's reputations are at stake. We should also have the professionalism to remind a gossiper firmly that rumours can have serious consequences.

For the record, I was not a member of the UK delegations to the recent meetings of WG14 and WG21 at Lillehammer. I actually attended both those meetings representing Plum Hall (Tom Plum's Hawaiian based company) and as a reciprocal liaison between WG14 and WG21. However, you should not make any deductions from that, though some seem to wish to do just that. You should also note that Lois Goldthwaite attended the WG21 meeting as HoD for the UK. She is a well-respected member of the International Standard's community and the editor of the Performance TR. Any suggestion that she would not have been part of the UK delegation to WG21 is clearly ludicrous.

At the recent meeting of WG21 in Lillehammer (Norway) someone commented that evolution took place by random mutation rather than by intelligent design. So perhaps Bjarne Stroustrup should be given the title 'Random Mutator of C++.'

Joking aside, there are many proposals for change and enhancement of C++ on the table. These are not exactly random but they do depend upon what matters enough to individuals for them to take time writing a paper making a proposal. There are probably many other good ideas that just have not been put forward.

If you have something that you feel you want to be considered then you have very little time left. We decided in Lillehammer that we definitely would not consider new proposals for change to the core of the language made after the pre-meeting mailing for the October meeting. It would also be fair to warn you that we are making no guarantee to consider new proposals made between now and then, just that we will not reject them out of hand. At this stage, writing a paper and expecting someone else to present it for you will be a waste of time. If you do not care enough to be at the meetings to promote your proposal, it will simply die (unless someone else feels that it has a great deal of merit)

The current number of proposals is extensive. The vary from very simple additions and changes to keep C and C++ in line with each other (for example, adding long long - yes you may hate it but continued resistance would simply use energy that is better spent elsewhere) to extensive proposals such as those for concepts. We have come a long way since the early meetings of the evolution group three years ago. We are beginning to see what it is that we want to achieve. I have little doubt that some of the newer participants will feel hurt when we do not select their proposals. Several of these people have specifically joined WG21 so that they could promote an idea that they believe to be valuable. These people are probably right, but that does not mean that the value will be great enough to incorporate them into the next version of C++.

Now we have all the mutations, sorry proposals, on the table we enter into the phase of natural selection. There is no reasonable way that all the excellent proposals will make it into the next version of C++.

I often suspect that most people have little idea of how much work goes into adding even the simplest feature. No one doubts the good intentions and hard work of those making proposals but they have to realise that they are asking other people to do a great deal of work as well. Simple assurances that something will work as described are not enough.

If you have the slightest doubt about this, consider ADL (argument dependant look-up). The original proposal for this came from a highly respected source and it was only after several years of intense experience that the holes began to show. We do not want to make the same kind of mistake again. C++ is not some instant language that can be fixed on the fly or by the next release from its owners. C++ is a language for serious programming and needs stability if it is to meet the needs of its users. Changes to a widely used language are expensive if the language is used for anything other than instant programming for instant disposal.

Now, even if you have not made any proposals for changes and additions to C++ you can do your bit to help the selection process. Have a look at the proposals (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/) and decide which ones look particularly attractive to you. When you have done that, offer to help those making the proposal. If you want something, be willing to give it a push to try to get it further up the ladder.

Get involved, pick a proposal you like and write a short (or long if want to) piece explaining why you would like to see it in C++. Send it to me and I will both see it is published here and that those concerned with WG21 see it. We cannot do design by democratic vote but that does not mean that we do not listen to the opinions of users.

int foo();

int i;

class x;

int i;
int& i_ref (i);
int bar(int parm, int & parm_ref);

int i(0);
int * i_ptr(&i);
int & i_ref(i);

From time to time, I come across pieces of hardware that seem to show some promise. One of my on going irritants is that manufacturers often fail to understand their product and so fail to make full use of it.

The hardware for this product is very simple. It consists of a special pen that signals its location when the nib is pressed for writing (with a cartridge of ordinary biro type ink) and a clip similar to that you have on a clipboard. All the special electronics is hidden in the clip and receives the pens signal. It transmits the information about the pen location to the PC through a USB connection.

It comes with some special software to handle the data supplied via the USB port. This allows you to draw on an ordinary sheet of A4 paper held in the clip, an application program captures what you draw on the paper. Out of the box, that is it. There are a couple of extra programs available on the web site and if you have Microsoft's handwriting-to-text engine one of these allows you to write on the paper and have it converted to text. That is quite impressive, but the Microsoft software is doing most of the work.

The first thing to note is that this product is MS Windows specific. The provided software is of no use if you have an Apple machine or a Linux based PC. That is silly; it is not that hard for a reasonable programmer to supply software for the other common operating systems.

[It is not that simple, mainly due to the way that different operating systems access hardware and to my knowledge, there is not any platform independent way to do this - PFJ]

The next problem is that the software interferes with some other uses. I have to remember to exit from the support software if I want to play most modern computer games, because the supplied software puts the game into sleep mode. Not a big problem, but one that could and should have been avoided. Moreover, I wonder what other software will have similar problems of co-existing with the PC Notes Taker software.

Now the big issue is why they think that they should be selling such a limited set of applications for their hardware. Given the way the product works, it clearly has the potential to be a mouse substitute. Even better, we could use the product to create a form, print out multiple copies and use those for capturing data. The handwriting to text would convert from the handwritten paper copy to an electronic version.

I am guessing, but I think there are a good number of people who would welcome such a tool.

If the manufacturer published the interface information for the hardware all the above problems would be solve. There are dozens of competent programmers who would jump at the chance to add value to the hardware. As it is, the product will have a minuscule market, remain relatively expensive and will die as things like tablet PCs become popular and cheaper.

When will the industry learn that trying to do everything results in an uncompetitive product? Let others enhance your product and you end up with lots of sales without too much investment. Just look at what happened to the PC once IBM gave up trying to control it.

Even better, letting others write extra software promotes the product because the software will help make the hardware better known. If I see a piece of software that solves a problem for me if I buy a relatively cheap peripheral, I am quite likely to make the purchase. Software sells hardware, the reverse is very rarely the case.

If you have experience of this product or products like it, I would be happy to hear from you and publish your comments and experiences for the benefit of others.

Here is a miniscule program. Now I think it is clear what the programmer intended but what do you think a conforming compiler will do with it and why? How should the author have written the definition of p?

 struct data {
      int i;
      int j;
 };
 int main() {
      data** p = new (data*)[5];
 }

What is the portability problem with the following small C++ program?

#include <iostream>

int main(){
  std::cout << "Hello World" << std::endl;
}

At first sight, there seems to be nothing wrong with that program and I guess you will find it (with minor variations) in almost every introductory text on C++. However whether a compiler will compile it depends on the implementation.

The problem, which comes as a surprise to a great number of C++ experts is that there is no requirement in the standard for the iostream header to include either istream or ostream. Without the istream header the compiler will not find a declaration of appropriate versions of operator<< nor of std::endl.

Now we can make a good case for such omissions because, for example, a programmer might not want to suck in the whole of istream just to use std::cout. However, the result is to create a surprise for programmers the first time they meet an implementation of iostream that does not include istream and ostream.

Here is last issue's clue:

I guess that many of you found that a tough clue. The two parts of the clue are interwoven. First clue consists of 'first course' and 'University'. The second part is 'C++' and 'Rome'. Both give 101 as the answer (i.e. 100 + 1).

Note that the second part of this clue will not be general knowledge for most people. But if you can get the first part, Google will help confirm it.