Title: Francis' Scribbles

I spent the last two weeks of October in Redmond attending three Standards meetings; WG21 (C++), ECMA's TC3/TG5 (C++/CLI) and then WG14 (C).

WG21 is working very hard on developing the next release of the C++ Standard (scheduled for some time about 2008/9). There are a great many good ideas for improving or developing C++. Quite a number of these are originating in the UK.

However, to my mind, the most important paper N1680 (available at www.open-std.org/jtc1/sc22/wg21/docs/papers/) was not a direct proposal but a discussion document. It is co-authored by A. Alexandrescu, H. Boehm, K. Henney, D. Lea, B. Pugh, and entitled 'Memory Model for Multithreaded C++'. The paper makes it clear that providing proper support for efficient multi-threading is more than just adding a few libraries. It is not necessary to change the syntax of the language to provide correct underpinnings for multi-threading but some changes to the semantics are essential.

Trying to implement multi-threading on top of a single thread abstract machine simply cripples modern multi CPU, multi-core hardware. In fact even such primitive developments as Intel's hyper-threading has to be turned off for many programs to avoid complete chaos. It isn't just the assumptions that programmers make, but those that are made by the compilers.

If we had to design a suitable abstract machine from scratch we would have a task that we would almost certainly get wrong the first time (Java did, and its designers were neither naïve nor ignorant). However we can capitalise on the experience of others and we have suitable expertise within the C++ community. What I have some doubts about is whether we actually have the will. Many people seem to think that the solutions that are already available through such libraries as the Boost one are good enough. I do not think they are and I think that once you spend time understanding the above paper you will agree. However the argument that what we have is 'good enough' is a very seductive one because, if accepted, it allows us to go away and do those other simpler things that we understand and want in C++.

How urgent is it to provide a suitable memory model for multi-threaded C++? Well C++ will have many fruitful years left even if we do not change the abstract machine. But those years will be numbered. Already AMD has sampled a dual-core CPU (i.e. two independent processors on a single chip). Intel have announced that future versions of their Pentium line will be multi-core and Sun Microsystems are soon to release an 8-core processor. The upshot is that we are only a very few years away (perhaps as small as two) from entry-level machines having, effectively, multiple processors.

Note that this development has been clearly coming for several years though the present competition between AMD and Intel has probably brought it forward a couple of years. Every attempt at increasing performance by increasing CPU speed involves increased heat production. The current speeds are now pushing the limit of what can be handled by air-cooling. When chip designers start muttering about having to go to water-cooling you know we will have problems, particularly with low-end hardware.

The only viable option is to increase computing power by having more processors doing the work. From the hardware designer's perspective this is not a big problem. The problem comes from the software end. The big number-crunchers have been using multiple processors and big array processors for years. But getting effective use from such hardware has meant developing specific development tools for the hardware in an area where software tools are expected to cost orders of magnitude more than those we customarily use for desk-top software development.

Now simple mathematics comes into play. Place C++ head-to-head with a language such as Java on a single CPU machine and all the traditional arguments of compiled versus interpreted code, manually managed memory resources versus garbage collection come into play. In its own specialist areas each language will be able to capitalise on its strengths and make a case for continued use.

Move to a multi-processor environment and any language, which can be used to make efficient use of all the computational resources available, will outperform one that is tied to a more primitive model. A lock that stops all other threads is a potential disaster on a multi-processor machine. Suddenly half your power is lost on a primitive dual core machine, much more on the more advanced hardware that is on the horizon.

The upshot is that either C++ evolves to make good use of the coming hardware or it will lose out to newer languages. Such issues as support for garbage collection are of minor importance.

Now the interesting thing is that if we get the fundamental memory model right library designers will be able to provide efficient components for the application level programmer. The latter will have to learn a bit about multi-threading (actually. probably less than what you have to learn today) but will get good use of the available hardware. If we do not get the underlying model correct, no amount of excellent library design will compensate.

WG21 deliberately make all the development papers available for general reading because they hope that others will review them and add their insights and knowledge in order to improve them.

Just because a paper makes a proposal does not mean that it will be in the next version of C++. Indeed a great many good ideas will fall by the wayside. One certain way for an idea to fail is if it is not actively pursued. WG21 have more than enough to do without taking on work from others. If you see a proposal that you would like to see followed through, at the very least provide the authors with moral support and encouragement. They need to know that others think the effort worthwhile.

If you are in a position to do more such as contributing your knowledge and experience of prior art, or volunteering to try the idea out by modifying a compiler whose source code you have access to then please come forward.

One of the hidden costs in pursuing any proposal is the fact that other good proposals will die. We just do not have the resources to follow every good idea. And even if we did, doing so would not be good for C++. I know some people think that there should be a nice coherent development plan for C++. Great idea but it just does not happen that way. What gets done is what people are willing to do.

If you want to add a major feature to C++ like full support for functional programming (just to choose an area where there is some interest but no existing proposals so I will not be hurting anyone's feelings) you will have a much better chance for success by getting together a group of people who will do the work (and that includes coming to meetings). Sorry if you do not like that message but it is the practicality of the situation.

An example of how that works is the 'Embedded C' TR that was produced by WG14. Those that wanted support for such things as DSPs got together, came to WG14 meetings and did the work.

Others have sat on the sidelines and criticised their doing the work for a whole range of reasons. Such criticism is unfair, inappropriate and, in my opinion, unprofessional. The group believed they needed support at least to the level of an ISO Technical Report, they put up the resources and no little cost to themselves and did the work. With more support and more expert eyes the result might have been better and more comprehensive, however I do not know that. What I do know is that those who simply tried to vote the work away on the basis that it should never have been done demean themselves and those they represent.

Shamefully, for reasons that I cannot explain here, the UK has been the worst offender over the last few years. Steps are being taken to correct the position but it would never have happened had the broad UK C community participated rather than sitting on the sidelines expecting others to represent them and their needs.

By contrast the UK C++ community has been one of the most active contributors to the future development of C++. We may not be able to send many people to WG21 meetings but our BSI Panel meetings are well attended and bubble with ideas and enthusiasm. Panel members have been putting in time and personal resources to help make C++ better. We do our best to ensure that C++ becomes better, and better meets the needs of its users. Most participants have a broad programming base and actively program in several languages.

You will have noticed that one of the three meetings that I attended in Redmond was an ECMA meeting concerned with the development of what is called C++/CLI. In other words a 'dialect' (Herb Sutter likes to call it a set of bindings, but most of us think that is too simple a view) of C++ to be used with the ISO Standard to which .NET conforms.

I hear a good deal of criticism of the ECMA process. I agree with much of it but there is one thing of which I recently became conscious and that is that the radical difference in the natures of ECMA and ISO do legitimately lead to a different process.

ISO Committees are composed of National Body delegations. Those delegations are supposed to represent their national interests. Indirectly those will include a substantial element of their nation's commercial interests. However note that this is indirect. ECMA Committees are composed of direct commercial representation.

It is perfectly natural that a decision made in TG5 should be dominated by the commercial interests of the participating companies. Such things as currently planned shipping dates are important. The process will be designed to take much more direct consideration and input from the participating companies.

ISO committees naturally have a wider community to serve. Where it becomes interesting is when we have a situation such as that of WG21 that is colocated with a strong, technically competent NB Committee (J16). Like ECMA, J16 is largely based on corporate membership. Like ECMA, J16 members are focused on the needs of the companies they represent rather than a broader community. Often the tension between WG21 and J16 goes unnoticed but sometimes it pokes above the surface.

I am greatly in favour of technical work being done together without too much commercial influence but it would be a mistake to ignore that the latter exists and that in the case of both WG14 and WG21 the (overwhelming) majority of attending experts are actually from J11 and J16.

Sometimes areas (such as what new work should be done) are definitely the domain of the ISO Committee and not a National Body. Yet sometimes the way that proposals get discussed means that the dominant position of experts from a single country can distort the outcome.

A case in point is a proposal from a UK expert that WG21 should produce a TR on a Statistics Library. The UK had only two people at the Redmond meeting. I had my hands full with the work of the Evolution Group. Most attending NBs had only one or two representatives. The result was that when the WG21 Library workgroup considered the UK proposal for work on a Statistics Library the discussion was dominated (overwhelmingly) by the J16 experts. A number of strong voices had good commercial reasons for not wanting to add a Statistics Library even as a TR. Note that I am not criticising those J16 experts, they were doing their job; the job that their employers expect and pay them to do. It just is not the same job as that which should be done by a National delegation to WG21. Indeed the official US Delegation often has a markedly different as a national delegation to that of the members of J16 as members of J16.

I think we need to address the issues that this raises. But before we do, we need to be willing to provide (or acquire from other NBs) the resources to do the work. When it comes to the crunch, it is those who do the work who will determine what happens.

It is no use sitting on the sidelines and whingeing about things we do not like, we have to get in there and get involved.

While much of the above is from a UK perspective, much of it would be valid from the perspective of other National Bodies.

Some programmers seem to hate to use more names in their programs than they absolutely have to. Your challenge is to write a program in C++ that outputs the first n members of the Fibonacci series where the value of n is provided by user input at runtime.

That is easy for most readers. But there is a limitation, any variable, function, type or namespace that you declare must be called i. You are allowed to use anything you like from the Standard (such as main, std::cin and std::cout).

The requirement that it be written in C++ is because I do not think it can be done in C, and there maybe some other languages in which the problem is trivial.

In case you think it is impossible, I have a solution (which took me about ten minutes to develop - but I have the advantage of knowing the key to coding the problem) that is fifteen lines of code with not more than one statement per line.

Here is a minimalist version of main():

int main(){
  a * b;
}

Given suitable precursors it will compile and execute. Can you provide suitable precursors so that the resulting program executes and outputs:

int main(){
  a * b;
}

This is a version of an old problem, which is to write a program that outputs itself. In considering answers I am interested in more than just a program, I want to see the mental process by which the author arrived at it.

The first problem with the above code is ensuring that (a * b) compiles. There are two possibilities, either a is a type and b is a pointer to that type or a and b are both global objects with an operator * that can be called.

If a is a type then the output must be generated by some other code that will be run by executing the program. That basically requires that there is a global object with has a constructor or a destructor that somehow causes the output.

If a is not a type then both a and b must be global objects (because they must be declared somewhere.) There must also be a suitable operator *.

Once you recognise that the output must be generated by some code that runs outside main() you are left with a number of options. Here is one that I wrote earlier:

#include <iostream>
struct work {
  work() {
    std::cout << "int main(){\n"
              << "  a * b;\n"
              << "}\n";
  }
} x;
int a, b;
int main() {
  a * b;
}

The submissions I have had so far have gone for more complicated solutions. That does not make them bad but as a general rule good programs achieve their objective with a minimum of complexity.

I forgot to give a closing date so I am not going to select a winner until the end of November (which will be too late for inclusion in this issue of C Vu.) For obvious reasons, it will be too late to enter by the time you read this.

Last issue's clue seems to have provided rather a different problem to readers. Several of you wrote to me with the number itself but were struggling to produce an alternative clue. Here is the clue again:

Oh for love in the sea! It only values the fifth bit.

The first three words give 040 (love is conventionally used in cryptic clues as 'o' (as a letter) or '0' (as a number) because of its use in such things as tennis scores. Now, in C that means 32 (octal 40). The second sentences provide confirmation because that is the value of the fifth bit in a byte (hey, we are C or C++ programmers and so count from zero).

Here is another clue to keep your brain cells working over the holiday season:

Deuce, it sounds like they came for tea twice. (4 digits)

There is plenty of potential for alternative clues. Something that happened on November 15, 1971 might be of use as clue material.