Title: Francis' Scribbles

Soon after becoming editor of C Vu I received an invitation from the editor of .EXE Magazineto write a short regular column about C. I think my first one appeared in January 1990. At that time I was limited to 500 words. Soon after, Mike Banahan, Chair of the European C++ User Group, was given the other half of the page to write 500 Words on C++. In those days I sometimes dropped my column in preference to a more substantial item on a new compiler release or other relevant item. After a year, Mike decided that he did not want to continue and I found myself with a whole page. When Will Watts stopped editing .EXE I found myself acquiring two pages for my column (about 2000 words) with the freedom to write about whatever interested me in the world of C & C++ Programming. That column continued till the death of EXE - the dot had got lost somewhere along the way. C++ Report ceased publication in the same month. That left me with more time and a substantial hole in my budget - the EXE column funded my Standards work.

Now, having also shed my work as editor of C Vu, and being in the process of phasing out my work as production editor I find myself with a little time to write a regular column. I intend to model it on my EXE Column, that is as long as you, the readers, enjoy it that way.

I will include a short coding problem in each column and after the first one I will also give you my answerto the previous one. It will be nothing as complicated as Herb Sutter's Guru of the week items, just a little problem to stretch our brain cells. If you want to discuss it on one of ACCU's mailing lists, that will be fine, but please also include editor@accu.org in the loop so that James can convert suitable items for use in C Vu.

The problem with writing 'C/C++' is that it implies that there is some kind of fusion between the two languages. There is enough commonality in syntax and semantics so that we can write source code that will compile to do the same thing. However there are many little differences as well as some big ones that makes such code something that has to be written with care.

I have become increasingly conscious that the use of 'C/C++' creates a mental attitude towards programming in these languages that is fundamentally flawed. That is why I am advocating that people stop referring to the two languages that way and replace it with 'C & C++'. You may think the change is too small to signify but I disagree. The exact way we express ourselves often carries hidden messages. Think of the implications of 'talk to' as opposed to 'talk with'. The real change takes place in the speaker/writer who consciously chooses between the two. The reader/listener may not note the difference but even then they may be subtly influenced.

If you have a view on this please send it to the editor but copy it to me because I will be interested whether you agree or not.

Over the past few years I have selected a book from the year's publications for my 'Book of the Year'. I have been surprised to find how much some authors treasure that personal statement. However I think the time has come for us to move on and make this selection one that you, the members of ACCU, participate in. The way I propose to make it work is as follows:

I believe that we have a conference programme for the ACCU Spring Conference 2002 that is second to none anywhere in the World. When you couple that with a cost that is cut to the bone (the whole four days costs less than some events charge for a day) I think you can understand why I think that it is the one event that every one should strive to attend. If costs are a serious problem then check the offer made in the last issue of C Vu. No one who takes their programming seriously should miss this event.

I realise that in reality there are many reasons why some will miss this event, but where there is a will there is a way. Just go and look at the speaker line-up. Most people just look incredulous when I say that I expect the World's best speakers to come to our event because they think we could not possibly afford to pay them. Well we can't, but that is not an issue because they are willing to speak just for the pleasure of being involved. If you truly want something you can get it. I wanted the best conference in the World, and I am half way there, the other half is up to you.

I just have to share this with you out of sheer frustration with the way that our good work can be messed up by the marketing and sales people.

I was setting up a new system with XP for a client (and I agree with my son, XP is by far the best operating system that MS have produced. That is not to say that it is perfect but...) and they wanted Roxio's Creative CD installed (though XP has direct support for CDR/RW).

I checked on the web and found that the software provided had to be patched. I got the patch. All was fine so far.

I installed the software from the CD and thoughtlessly rebooted before installing the patch. Bad, bad move. On reboot XP declined to load the drivers on the grounds they were not compatible, nor would it load its own drivers. No doubt given time, I could have worked out what to do next but the obvious solution seemed to be to uninstall Roxio's product.

No can do. The uninstall needs to read the installation CD. This is not the first time I have encountered such lunacy but it really is down right stupid. Apart from anything else, how does an honest parent remove pirated software from a child's machine?

As I had not done anything other than install XP, the simple answer was to reinstall everything from scratch.

Now if you work for a company producing shrink-wrapped software could I suggest that you check to see that those people in the front office are not lowering the customer perception of your work by doing silly things like this.

Just to give you another example, the Harry Potter game does not seem to install correctly on anything but the C drive. Maybe there was some other problem but that was the way it looked to me. Very irritating because I try to restrict what goes on my C drive to those things that have to be there for technical reasons rather than because some idiot cannot write correct and robust (un)install routines.

Some of you may know that I recently became a moderator for the above newsgroup. It is quite interesting, though sometimes a little tedious. The most likely culprits for flaming etc. are actually very well respected and knowledgeable experts which means that one has to carefully read everything before accepting it.

In general it seems that I usually top the monthly lists of posts to the group closely followed by James Kanze. Actually James writes far more than I do because he is a proponent of the long and fully responsive post while I tend to be overly terse. This cosy position was broken by a newcomer. He burst on the scene with what he claimed was his first ever attempt at writing a class and was also a fabulously (my word, not his) fast implementation of a subset of the string specification. The trouble is that the moderation procedure does not allow us to reject posts just because the writer is an aggressively enthusiastic idiot with a completely overblown concept of his ability.

If you want to see just how stupid someone who claims to be a professional C programmer with fifteen years of experience can be wander over to Google and have a look, you won't have much problem with finding his posts but I cannot mention his name because the editor thinks that is unfair. You won't want to look at many of the posts before tedium sets in. He mentioned that he only had about three months before he would have to find some more employment. The response from one reader (which was never posted because it was a manifest flame) was to tell him that he should a) Persuade Google to remove all his posts from their archives and b) only post to the web with a well-disguised alias.

Now the irony is that in all his 'bull in a china shop' thrashing around he managed to highlight a problem with Dinkumware's implementation of std::string related to how they handled assignment and reserved memory. PJ Plauger had done something apparently sensible (in the broader context) which really killed performance if you tried to append lots of single bytes. Once the problem surfaced it was quick for one of the other library experts to point to a better solution. However you can just imagine what that did to the original poster's ego.

The moral is that even the most stupid person can sometimes identify a problem. I am very much in favour of listening to novices because they bring a new perspective that sometimes let the more experienced gain insight. However, how much better it is when they show respect for the skills of others. Arguing with David Abrahams as to the meaning of the strong exception safe guarantee just shows ignorance. Continuing to argue when told that the term was actually invented by David is just plain rude.

Is it not curious that so many people confuse the tool with the problem? I get tired of reading advice that basically says that classes that have pointers as data members need user written copy constructors, copy assignments and destructors. Such a requirement has nothing to do with pointers, though their presence is often an indication that resource ownership needs to be considered.

The fundamental problem is that when an object owns resources we, as programmers, have to handle that ownership. There are two places where the problems will be most visible, when copying and when destroying the object.

These days it would be rare to find an experienced C++ programmer who used a raw pointer as a handle for some dynamically acquired resource. Instead we would use some form of smart pointer whose destructor released the resource. The simplest pointer for such purposes is an auto_ptr. And if we want a dynamically allocated array, a std::vector (or possibly a basic_string) would seem to be the tool of choice.

Using this kind of tool solves two problems: it deals with some of the exception safety issues that pertain to constructors by ensuring that acquired resources are correctly released if the constructor fails, it also makes it likely that you may be able to avoid writing a destructor. It does not fix the problems of copying.

One of the things that programmers need to learn about is copying and the variety of semantics that can be attached to the process.

In the case of auto_ptr we have a strict ownership semantics based on the concept that only one thing can own the resource. Copying in those terms means transfer of ownership. Actually that is not what most of us think of as being copying, but how else do you deal with a unique resource? Well there is another solution which is shared ownership and various manifestations of this concept are found in counted_ptr, shared_ptr etc. But notice that using such smart pointers involves a very exact concept of ownership, which again provides a counter-intuitive version of copying. If you intend that all copies of an object share a resource then fine, but it may have hidden implications when you start moving into multi-threaded code.

If you want to automate copying of objects that own resources you will need another kind of pointer, one with deep copy semantics. I.e. one where the process of copying the pointer copies the object pointed to.

No doubt there are other issues that I have not considered but the point that I want to make is that just knowing the idiom of using auto_ptr or vector instead of a raw pointer obscures the underlying design issues. To deal correctly with resources you need to understand ownership in a way that is far more fundamental than that presented in most books and courses. In addition these are not C++ issues but programming ones. C++ provides a good set of tools for dealing with ownership issues. To use the tools correctly you must understand the issues.

Is there anything that you think you wish C++ did that it does not do at the moment? Or perhaps there is something that can be done but only by pushing general coding skills to the limit.

I often hear people say that library fixes are to be preferred to language ones on the basis that you do not need to fiddle with the compiler. I can understand that, because changing the language has to be done very carefully lest a seemingly small change has unforeseen consequences elsewhere.

However, library fixes are not cost free. Sometimes they involve very convoluted use of template technology that expands compilation times and makes source code more fragile.

I think we should be looking at ways to simplify code so that writing correct code becomes easier. Indeed if you look at general technological development you will see that things go in cycles. We start with something that is very simple and then progressively complicate it. Then there comes a new grand simplification. If you think carefully you may come to the conclusion that the original attraction of C++ (in the mid 1980s) was just that it allowed writing C like code to be done more simply. And then we went through over a decade of complicating it.

I think it is time we looked for new simplifications. Curiously extending the language can simplify it by allowing us to express more complex ideas and intentions in simpler ways.

On the other hand we can simplify things for application programmers by providing them with more powerful and more extensive libraries. Libraries that have been well designed and thoroughly tested before being added to the standard. This is part of the reason for the existence of boost.org.

I wonder what criteria you would have for deciding how we should add elements to the Standard C++ Library. In the past people have been reluctant to consider giving library support where there is more than one reasonable approach. For example random number generators are far from simple because you need to consider such things as distributions (rectangular, normal etc.) as well as simple ideas as to quality of randomness.

However the work of people such as Andrei Alexandrescu with his policy parameterised templates show that we can provide such things and allow each person to have something that exactly meets their needs.

On the other hand things that would appear to be cost free prove to be otherwise when we investigate further. For example it seems perfectly reasonable to extend the language by providing compiler generated virtual destructors for any class that has a virtual function.