The Casting Vote

Poised on the brink...

As I have explained in previous columns, the process we follow in standardising C++ means that once we reach a certain stage, we can no longer make "large" changes. Stockholm, July '96 was that stage and we resolved to make no further changes unless the National Body comments require us to do so.

This left us in a somewhat difficult position since we had some fairly large unresolved issues on the table. Fortunately, as in so many projects, the impending deadline spurred us on and we made great progress, finally reaching consensus on some long-standing issues.

Lists of lists

Over the last few years, the number of large issues has dwindled and we have quietly got on with solving the smaller problems. Each part of the language and each part of the library has provided a steady stream of minor things to deal with. Each part has had a nominated member of the committee as list-keeper and they have worked with subgroups to produce workable resolutions that the committee as a whole should adopt. For example, in Core III (formerly Extensions) WG, John Spicer of Edison Design Group has handled the template issues, Bill Gibbons (ex-Taligent, now HP) has handled the namespace issues and pointer to member issues and Dag Brück (Dynasim, Sweden) has handled the exception handling issues. Like the other WGs, we worked through each list, discussing and generally approving the suggested resolutions. Each list went forward to the full committee for approval of the resolutions and thence into the Working Paper. We cleared all of the exception and namespace issues and all but two very minor template issues.

The various Library WGs had the longest lists to process and they managed to clear nearly everything (literally hundreds of issues) and that got them a round of applause from the full committee!

This doesn't mean we're finished, just that we can now concentrate on the even smaller issues that make standards such a thrilling business (if you like that sort of thing).

Where should I put my templates? Revisited

An ongoing theme of this column is templates and in particular the source model required for portability. You may remember that in my previous Casting Vote column, I said that X3J16 voted in Santa Cruz to remove separate compilation, pending a further vote in Stockholm. Much has happened since! Silicon Graphics (SGI) worked very hard to produce a solution that would be acceptable to enough people that we could vote to keep separate compilation. Their solution involved several changes that restricted templates and made them more intuitive regardless of the source model.

Ultimately we still needed one key piece to solve the puzzle: how to determine whether a template definition should be available outside its translation unit. SGI's proposal originally suggested that declaring a template extern should have the desired effect. Overloading extern in this way was not terribly popular with the WG so I suggested export. After some further discussion, this was accepted.

This means that existing template code that uses the source inclusion model will continue to work pretty much unchanged. Code that is intended to work when template definitions are compiled separately must be modified to declare the definitions with export. Since no two compilers handle separate compilation of templates in the same way, this shouldn't be too much of a problem � such code isn't portable at the moment anyway.

// export tells the compiler that this
// definition might be referenced from
// another translation unit so it must
// squirrel the definition away somewhere:
export template<typename T>
void soSomething(T t) { ... }

// this template is not exported so the
// compiler can assume that it will be
// defined identically in every translation
// unit that references it - it need only
// perform any instantiations found in this
// translation unit:
template<typename T>
void doSomethingElse(T t) { ... }

Stringing us along

Some years ago I proposed that string literals be made const. The proposal was quietly brushed to one side and I let it lie. The UK panel remained unhappy about the issue and recently Kevlin Henney produced a new proposal to achieve the same goal. Although our proposals were largely identical, so much has changed both within the language and within the committee mood that Kevlin's proposal was accepted. See Francis' article below for more details on this.

Out! Out! Damned name injection!

Yes, we finally got rid of nasty old name injection. Again, this has been mentioned in several of my past columns and various attempts have been made to remove it in the past. Bill Gibbons finally came up with a proposal that solved enough of the problems to gain support from the majority of the committee. Quite simply, if a call to a function f involves a type T, friends of T (declared in T or its base classes) are considered in the lookup of the name f. This mirrors, to some extent, the operator lookup rules adopted recently � the so-called "Koenig lookup". This lookup has now been uniformly adopted for all operator and function calls, both inside and outside templates.

Note that this is a fairly major change, affecting far more than just friend name lookup: it means that the language now has one well-defined process for all name lookup, regardless of templates, that has the appropriately intuitive behaviour in the presence of namespaces, i.e., whenever an object whose type is from a namespace is used in an expression, all "related" functions and operators are "automagically" considered. This should make namespaces much easier to use.

Inching closer

The amount of consensus in Stockholm means that we should now release the second Committee Draft after the Hawaii meeting, triggering a second ANSI Public Review, and hopefully moving on to a Draft International Standard in the middle of 1997. At that point, the draft becomes something that can be referred to with authority because the remainder of the standards process � bar minor typos � is a rubber-stamping exercise as far as the majority of working programmers is concerned.