Title: Francis' Scribbles

Author:

Date: 07 April 2002 13:15:50 +01:00 or Sun, 07 April 2002 13:15:50 +01:00

Summary:

Body:

Book of the Year 2001

When I wrote my last column I felt certain that the ACCU membership would grab the opportunity to give credit to authors that had helped them. How wrong could I be? Just three people went to the trouble of emailing me a list of any kind. As the whole point of the exercise was to break away from the past where I made up my mind as to where to cast my favours I am left with a problem. Authors value the plaudit of having their worked designated as book of the year by organisations such as ACCU, and I am sure that many would value even a nomination. We need to give every encouragement to good authors. That means more than just buying their books. We need to tell them what we like and what we do not. Reviews do part of the job, but there is more.

Having thought about it, I have decided to ask those attending the ACCU Spring Conference to make nominations on the first day. Perhaps by way of encouragement I will persuade Blackwells Bookshop to provide a small prize that can be drawn for from those who have provided nominations. Unfortunately this has disenfranchised the membership from voting, but I think you lost your vote when you chose not to make a nomination.

Conference Concerns

I have had several emails as well as a couple of posts to comp.lang.c++.moderated concerned with various aspects of the conference. Let me deal with them here.

Several people are unhappy that it is so close to Easter. There are very serious constraints under which we work. The timing of academic holidays is critical for many speakers, and note that this is not only UK academic holidays. In addition we have other events that interact. We could have held the event at the end of April in Curuçao but I think the consequential costs would have deterred most from attending. Why there? Because that is where about half the speakers will be at that time as that is when and where WG14 and WG21 will be meeting. The second week is out, because few speakers can afford to be in the UK for a week and then transfer to Curuçao. Extending their Easter break with a visit to the UK was possible. Both March and May hit problems with academic commitments. If we were to have a Spring event it just about had to be the first week of April. It is rather Holmsian, when you have eliminated the impossible whatever remains, however problematical, has to do.

The choice of location was not ideal but we were constrained by late decisions. Despite rumours to the contrary, I have never chosen the actual conference venue but I have specified that it should be accessible to me because I did not want to be responsible for an event a hundred miles or more away. You will see below that we are already tackling this problem for next year and I hope you will all support the result.

Now let me tackle costs. We try to keep these down and so do most of our speakers. Indeed without the generosity of most speakers and many employers we could not run this event as economically as we do. I know that is no consolation to those who find the costs have risen out of their reach but ACCU was willing to subsidise those for whom this was the case but no one asked. In round terms it cost £1000 per speaker in travel, accommodation and sustenance. And it costs £50 per day per delegate to hire rooms, provide refreshments etc. In addition there are promotional and administrative costs. You should budget for at least one person's working time for six months. In planning for next year I will be sitting down with our organiser and looking to see if there is any way to reduce costs in future but it will not be by any dramatic amount. Of course if we knew twice as many people would come we could probably shave 25% off the cost.

Promoting our events any way you can reduces costs by increasing attendance. We need employers to realise that this is the event to send their developers to. That is the message that has to be got home. We can keep striving to do better internally but we should make sure that those with the purse strings know that ours is already one of the most cost effective events available. Actually, I am quite certain that our events are the best available at any cost.

Getting management support is a long-term process. When you have been to an ACCU conference make sure management know, and continue to remember how useful it has been. There are many opportunities to gently push home the message, learn to spot them and exploit them.

I still find members who seem to think their membership of ACCU is something that they should not be open about with their colleagues. I am at a loss to understand this. The benefits of membership in general and attending our conference in particular are substantial and you should want your colleagues to know what they are missing. Which leads me to:

Telling People About ACCU

I was visiting Blackwells yesterday and noticed a lone figure struggling to choose a book on C++. Being me, and having a few moments to spare I started with one of my standard pick-up lines: 'Are you trying to learn C++?' That started a conversation in which I could point him to a suitable book (as he had done some programming before and knew the rudiments, though nothing about C++, Accelerated C++ was the obvious choice.) In the conversation he revealed that he was working for a local company developing educational software in collaboration with Oxford University. Now I have a way into a company that will certainly benefit from ACCU membership. Of course I still have to land the fish, but the hook has been planted.

The programming section of your local bookshop is a rich fishing ground for new members. It is a pity more members do not fish there. As the Bible teaches (and there is a lot of good advice there even if you do not believe that it is the word of God), do not hide your light under a bushel. We provide excellent value (for money, if you insist) but we need to tell more people.

Use your voice, use your email signature and use your initiative to spread the word. There has been virtually no growth in UK membership for five years. There has been growth but almost entirely in the non-UK membership. I think that if even 10% of the membership did just a little to promote membership ACCU would grow by at least 10% in the UK and by much more elsewhere.

Happy News

Those of you who know Herb Sutter may be surprised to learn that he has, until now, managed to avoid marriage. That is about to change as a young lady had both the good sense and the skill to hook him while he was in Seattle for the October WG21 meeting. I am sure you will all join with me in congratulating Herb and Tina (the wedding is scheduled for early May) and wishing them many happy years of matrimonial bliss.

I suspect that the other news about Herb is not unrelated. He has just started a job at Microsoft. His job title is 'C++ Community Liaison' and he will be working from Redmond.

I am not sure what happened but I am getting clear messages from several sources that Microsoft has radically changed its attitude to C++ and the C++ Standard. This change happened some time in the last year. A couple of the more visible hints are that they switched Stan Lippman from C# to C++ (that was quite a surprise when it happened last October) and this appointment of Herb. It seems that there is now a serious chance that VC++ will become a fully compliant C++ development system. I hope that Microsoft's senior management do not have second thoughts.

Future Events

The UK is hosting the Spring meetings of WG21 and WG14 in 2003. Barring some form of catastrophe these will take place between March 31st and April 11th at the Holiday Inn just outside Oxford. I do not know what experience you may have had of Holiday Inns. Mine has been mixed. I have only just discovered that some are franchises (and my poor experience of the one by Victoria Station, London is an example of such a case) most are part of a company with hundreds of hotels world-wide. The Oxford one is excellent. More about ACCU and Holiday Inns in another column.

Currently we are planning the ACCU Spring Conference 2003 to be collocated with the WG14 meeting. This will provide us access to speakers that would not normally be available. As WG21 will be the following week we will be able to draw on them as well. I think that will provide us with the basis for another outstanding event. It will also provide a potential platform for public discussion of issues of compatibility and co-operation between the two languages.

The facilities at the Oxford Holiday Inn will make organisation of such things as Birds of a Feather meetings as well as informal late night sessions relatively easy.

An Essential Tool

One of the things that continues to amaze me is the reaction that I too often get when I ask programmers about using lint. Many look blank and I find myself explaining that it was the tool that K&R never mentioned because it was so fundamental to good C programming that the authors just assumed readers would know about it.

In its original manifestation lint was largely concerned with inter-file dependencies. It was the existence of lint that allowed C to be written without visible function declarations. lint was deliberately very picky, so much so that some programmers hated it. However it was doing a valuable job by ensuring that many potential errors never propagated into production code. Of course more sophisticated tools have been developed. QA C is one that springs to mind. That product is expensive but fully justifies its cost if you are working on mission critical code.

C++ has many more problems, and some of those manifest directly in a single file. A decade ago Gimpel Software produced a product called PC-Lint for PC based development systems. It also produced a similar product, Flexelint, for non-PC systems. The later was (and is) fairly expensive (about $1000) because it has to be produced as shrouded source code so that it can be compiled for the platform of your choice. PC-Lint is not that expensive (current list price of $239). If you do not have a copy that you regularly use then perhaps you could write about what you do use for correcting the numerous coding errors that litter your code. Do not tell me there aren't any, I will not believe you and I am sure that passing a hundred lines of your code through PC-Lint will support my disbelief. From my perspective PC-Lint or something that does the same job is an essential tool for professional programming in C++ (perhaps Microsoft might license it and distribute it with VC++ 7.1, that would go well with their new found dedication to good C++ programming.)

I will try to write about it in more detail another time, perhaps for the Members Experiences section (well I am sure several of you could do so and save me the trouble). However let me tell you a little tale from my time as a teacher. When I sat down beside a pupil to work through some word processed material I would talk it through and make corrections as I went (or sometimes get the pupil to do so). When I had finished I would print out a copy and hand it to the pupil saying 'Here you are, we have corrected it.' There was usually a glow of pleasure in their eyes because it had been corrected rather than massacred with red ink. (These days I would switch on 'track changes' so that the original was preserved as well as the corrected form).

How does that relate to using PC-Lint? Well as you work through its diagnostics you have a choice between making changes and overruling the program with a correctly coded comment. In other words when a piece of source code passes PC-Lint without diagnostics all the causes of problems have either been corrected or have been signed off. That is exactly the right way. If I insist that my code is correct (and it probably is) then I can take responsibility and PC-Lint will stop nagging me about that item.

If you do not know about Gimpel Software Products surf over to www.gimpel.com and have a look. They (as far as I know) produce only the one product but it is one that you should not be without.

Solution to Problem 1

In case you missed it here is the problem again.

Look at the following small piece of C source code and identify all the issues that you need to consider when you want to import it to a C++ application and to compile it with a C++ compiler:

#include <stdio.h>
int const zero;
inline int foo(void){
 return zero;
}
main(){
  int i = zero;
  i= ++i;
  int j = foo();
  printf("%d", i+j);
  return zero;
}

Several of you thought that the code was not C. Surely you must have suspected that when I place such apparently wrong things in my C code as inline that I knew something you did not. Anyway, let me take the code line by line.

#include <stdio.h>

OK, nothing needs changing but many C++ programmers would prefer:

#include <cstdio>
int const zero;

That line works fine in C because zero will be zero initialised. If it were not for the const qualifier the same would apply in C++, but in C++ if const qualified only objects of non-POD type with a user written default constructor can be defined without an initialiser. So we must write:

int const zero(0);

By the way, I prefer function style initialisation because, in my experience, it causes fewer surprises.

inline int foo(void){

Now a surprise for those who have not been tracking changes to C, inline is now a keyword of C, though the rules are slightly different to those of C++. There is a problem, but it is not in the use of inline. The problem is that in C you must designate a single definition that is to be used when the code is not inlined. More about that another time.

 return zero;
}

That is fine but the following line is not. At first sight C programmers will just comment about implicit int, but that earlier use of inline tells us that this code is for the current version of the C standard. One change that was made in the latest version was to remove implicit int (and yes, that does break millions of lines of legacy code. However it is easy to fix with a one-time program to make the ints explicit so it is the class of changes that are acceptable even if some maybe irritated.

main(){

So we should amend that even for C to:

int main() {
  int i = zero;
  i= ++i;

Yes that line was thrown in as the easy to spot starter for one. It causes i to be written twice without an intervening sequence point so in both C and C++ (though not in Java) it is undefined behaviour. Pretty stupid as well but we need a few of those to keep you all awake. How quickly did you amend that to:

  ++i;

with certainty, rather than wondering if perhaps I knew something you did not?

  int j = foo();

And following that blatant error we have a blatant non-error. Another of the changes made to C in its latest standard is to allow late definition of variables.

  printf("%d", i+j);

That line is fine in C but probably needs amending in C++ to account for namespace std. How you amend it rather depends on what other choices you made earlier. If you did not change the header file then you can leave it as is.

  return zero;

Did you think about that line? If not deduct a mark. It is correct but only because zero has the value 0. If it had been something else then the results would depend on the implementation. While many of the common systems allow you to return any integer value from main, some do not and the Standard supports that option.

So how did you do? Perhaps I could rephrase that and ask you how I did? Are there any things you think I missed? Or things that I got wrong? Do not be afraid to say because one or other of us will learn form it. Once many years ago a fellow pupil told the Maths teacher that the answer in the back of the book was wrong. When asked to justify it, the pupil declared that it must be because I had a different answer. Such confidence, and misplaced at that. He was immediately appointed by the Maths teacher as secretary of my fan club.

My guideline is to always read code on the principle that there is one more defect still to be found.

Problem 2

#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;
}

So what do you think the output will be? Now be careful and double check. It would be nice if source code checkers spotted such typos and at least flagged them as suspect. Actually some will because they will issue an unused variable warning. Perhaps I have said too much. I would be interested in two things from readers. First how quickly did you spot the error? Second, what similar problems do you know.

Notes:

More fields may be available via dynamicdata ..