Professional Documents
Culture Documents
3rd Interview C++ The Making of A Standard Journey's End
3rd Interview C++ The Making of A Standard Journey's End
Chuck Allison
"So far, C++ has escaped the fate of the Vasa; it has not keeled over
and disappeared despite much wishful thinking and many dire
predictions."
When I attended the March '96 meeting of the joint C++ Standards
Committee (ANSI X3J16/ISO WG21) in Santa Cruz, I found that things
hadn't changed too much in the two years since I had last attended.
There were mostly familiar faces, and the talk mostly focused on
"When will we get this thing done?'' As far as the features that most
programmers care about, the specification of the language and library
is complete. The first Committee Draft (CD), a formal public review of
the working paper which essentially froze the features of the language,
took place in the spring of 1995.
The committee took the rest of that year responding to the several
thousand comments they received. At the July '96 meeting in
Stockholm, Sweden, the committee voted a final feature freeze. The
November '96 meeting in Kona, Hawaii should result in a second CD. If
that meets with general approval from national standards bodies
throughout the world, we should see an official C++ standard
sometime in early 1998.
To appreciate the work that has gone into the standard, as well as the
interview that follows, a little history is in order. For a detailed technical
and anecdotal history of C++, see Bjarne Stroustrup, The Design and
Evolution of C++ (Addison-Wesley, 1994). Also known as "D&E,'' it is a
must-read.
The base documents included the ISO C standard, and Ellis &
Stroustrup's The Annotated C++ Reference Manual (the ARM, for
short). The latter pretty much reflected AT&T C++ 2.0, along with
Bjarne's ideas for extensions (mainly templates and exceptions). The
main goals at the outset were to standardize iostreams, and to add
templates and exceptions to the language. Due to the large number of
non-US participants, the committee voted to work jointly with ISO
Working Group 21 at the Lund, Sweden meeting in June 1991.
It looked like things were winding down at the end of 1993, yet there
was still some uneasiness about a lack of robustness in the standard
library. At the San Jose meeting in November 1993, Alex Stepanov,
then an HP employee, gave a presentation on generic programming
which really put templates to good use. By the San Diego meeting the
next March, he had refined his and Meng Lee's "Standard Template
Library'' (STL) to the point that the committee was ready to seriously
consider it, even if it meant delaying the completion of the standard. I
remember being one of the conservative skeptics at the time, yet my
hand went up in favor of STL, which, along with iostreams, is now the
centerpiece of the standard C++ library.
The major topic of debate at the Santa Cruz meeting was the template
compilation model. Bjarne originally defined templates so that their
definitions could reside in separate compilation units, just like ordinary
functions can. Compiler vendors soon discovered, however, that it was
often easier to instantiate and optimize templates that were defined
totally within an include file. These two approaches are known
respectively as the separation and inclusion models of template
compilation.
More than once Bjarne's vision has brought things back to a sound
footing. When I asked if he would write for this journal, he had to
decline, due to a backlog of heavy commitments. He did, however,
consent to an online interview, the transcript of which occupies the
remainder of this article. Enjoy!
C/C++ Users Journal: I know you have a Ph.D. in Applied Math. What
were your other degrees?
CUJ: When/how did you notice that C with Classes was becoming
something that was going to consume much of your time, if not your
career (in other words, not just a temporary interest)?
Naturally, C++ will play a major role here, but I have no plans to limit
my interests to just C++. My department is part of AT&T Research. In
the breakup of AT&T, AT&T kept half of the information sciences
research of the old AT&T Bell Labs (the other half and the name went
to Lucent Technologies). The AT&T part is now called AT&T Research
and we aim to be a research organization second to none. To a
considerable degree, C++ is still my "day job.'' I work on standards
issues, help users, write papers, give talks, write books, etc.
Occasionally, I even get to write some code -- though not as much as
I'd like.
Some of the problems with "name leakage'' in the inclusion model can
be compensated for through the use of namespaces, but not those
caused by macros. The separation model requires attention to the
problem of how names are selected from the contexts involved.
However, the problems relating to context and name binding when
composing a program out of templates from different source files are
roughly equivalent to the problems you face composing the program
out of templates in separate namespaces. This is natural because
namespaces and translation units are two ways of expressing logical
separation. The implementor must face similar challenges in the two
cases.
CUJ: What improvements to templates were you referring to, and why?
list<int> li;
list<complex> lc;
list<shape*> lps;
list<char*> lpc;
list<node*> lpn;
would generate five copies of the list code. This can be a real problem
to projects. Having lists of dozens of different element types is not
uncommon, and this can lead to serious code bloat. The solution that I
have recommended from the very first paper on templates is to use a
single shared implementation for all lists of pointers. For example:
The <T*> means use this specialization for every instantiation for
which the template argument is a pointer. This allows users to vary the
implementation of lists without affecting the list interface. There are
several such minor extensions to templates that together represent a
major improvement to what we can express in C++. Here, I'll just
mention default template arguments. As an example consider sorting
strings of arbitrary characters. A (too) simple version looks like this:
template<class T>
int cmp(string<T>& a, string<T>& b)
{
for(int i = 0; i<a.length()&& i<b.length(); i++)
if (a[i] != b[i]) return a[i] < b[i];
return b.length() - a.length();
}
The problem is that operator< may not be defined for some character
type T. Also for different string types, you might want to compare using
different comparison criteria. An example would be comparing strings
of ordinary characters with and without case sensitivity. Though the
traditional and obvious solution is to make the comparison criteria a
function argument, a more elegant and efficient method is to make the
comparison criteria a template argument:
string<char> sc;
string<char> sc2;
cmp(sc,sc2);
is equivalent to
BS: My greatest hope is that it will teach many more people to use
C++ as a high-level language rather than a glorified assembly
language. My aim with C++ was -- and is -- to raise the level of
abstraction in code so that the program text directly reflect the
concepts of the application and general computer science concepts
wherever reasonable. Yet, far too many people get lost fiddling with
bits and pointers. The standard library allows people to take string,
vector, list, and map as given and delay worrying about C-style strings
and the pointer-level implementation of basic data structures until
necessary.
CUJ: You have often used the story of the Vasa to encourage taking the
simple route in defining the C++ language. But it is pretty much
common public opinion that C++ is one the most complicated
languages in existence. Any comment on that? If there are different
"levels'' of C++ usage, how would you characterize them?
BS: Clearly there was a danger; why else would I bother telling a
cautionary tale? Construction of the Vasa started in 1625, at the
request of King Gustav. It was originally intended to be a regular
warship, but during the construction the king saw bigger and better
ships elsewhere and changed his mind. He insisted on a flagship with
two gundecks; he also insisted on a lot of statues suitable for a Royal
flagship. The result was (and is) very impressive. Rather top heavy,
though. On its maiden voyage the Vasa only made it half way across
Stockholm harbor before a gust of wind blew it over; it sank killing
about 50 people.
It has been raised and you can now see it in a museum in Stockholm. It
is a beauty to behold -- far more beautiful at the time than its
unextended first design and far more beautiful today than if it had
suffered the usual fate of a 17th century battle ship -- but that is no
consolation to its designer, builders, and intended users.
So far, C++ has escaped the fate of the Vasa; it has not keeled over
and disappeared -- despite much wishful thinking and many dire
predictions. Some of the newer "extensions'' are seen as
generalizations that actually make life easier for C++ programmers.
My programs have certainly become shorter, clearer, and easier to
write over the years. I simply don't have to go through as many
contortions to express good design notions as I used to. Naturally, if
your view is that the best programming language is the one that lets a
novice get a demo running fastest, C++ doesn't fare so well, because
it certainly takes longer to master. However, my primary concern is
production code, and in competent hands, C++ is a delight.
C++ is of course quite complex when compared to, say the original
Pascal, but so is every other modern programming language.
Compared to the programming environments we use and the systems
we program for, however, C++ is still simple. For a novice, it would be
a serious mistake to try to first learn all of C++ and then start using it.
Instead, it is best to start with a subset and expand one's repertoire as
needed. I recommend starting with a C-like subset, but using the
standard vector, list, map, and string classes instead of fiddling with C-
style arrays and strings. Naturally, macros should be avoided and also
unions and bitfields. However, you can write very nice code with that
subset of C and C++ plus the four standard library classes I
mentioned.
Soon after, one can start experimenting with simple classes, simple
templates, and simple class hierarchies. I recommend focusing on
abstract classes before designing any non-trivial class hierarchy. Very
simple exception handling can also be useful early on. The most
important thing to keep in mind is to focus on the problem to be
solved, rather than the language-technical aspects of C++. It is always
easier to learn a language if you have an experienced -- and non-
prejudiced -- friend or colleague to help.
BS: I think most of the compromises were in place long before the
standards committee was convened. (See my answer to the next
question). The C++ specific major features such as classes,
namespaces, templates, and exceptions were constrained by a wish to
be able to generate very compact and efficient code, and to coexist
with code written in other languages, rather than anything C-specific.
Actually, most "compromises'' can be seen as driven by the "zero-
overhead principle,'' which says that any feature you don't use
shouldn't cost you anything in time or space. That's what keeps C++ a
viable systems programming language, and what has kept it from
evolving towards something more convenient for toy examples, but
less useful as a tool for everyday programming.
CUJ: Suppose for a moment that C compatibility was not an issue. How
would C++ be different, in your view?
Also, the sheer effort of finding and maintaining the appropriate degree
of C compatibility is not to be underestimated. C compatibility was one
of the hardest decisions to make and put into practice, in addition to
being one of the most important. However, there are many aspects of
C that I'm no fan of, so had there been a language as efficient, flexible,
and available as C without those features, I would have chosen to be
compatible with that. For example, I consider the C declaration syntax
an experiment that failed, and in general, the C syntax for declarations
is too lenient. Note that C++ has dropped the "implicit int'' rule:
static T;
static int T;
There are many such details that make life unnecessarily hard for the
compiler writer and for the casual reader of real life C and C++ code
(as opposed to trivial examples like the one above). I suspect my
dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++
implementations, but it is a hack, and so are most of the techniques
that rely on it. It has been my long-term aim to make Cpp redundant.
However, I wouldn't dream of banning it until long after it had been
made genuinely redundant -- and that hasn't happened yet.
I also find C-style arrays too low-level for most uses. However, I don't
consider C's success an accident. It was -- and often still is -- superior
to alternatives in enough ways to be the right choice for many projects.
Except, of course, when the alternative is C++. I have never found an
application where C was a better choice than C++ for any reason but
the lack of availability of a C++ compiler. If there is some non-C
feature of C++ that someone finds unsuitable for a project, it can
simply go unused there.
BS: What Java revolution? Java is (at least) two distinct things: A fairly
standard modern programming language with a superficial
resemblance to C++, and a rather interesting system for downloading
code into other people's computers when prompted through their web
browsers. The latter addresses hard, interesting, and important
problems. If the serious security problems with Java and Javascript can
be solved, this could be very important. It could be very important
even if the security holes are left open, because it seems that most
people generally don't care about security anyway.
CUJ: How will the existence of a standard change things in the C++
community? And for you personally?
BS: For the community: stability, better compilers, better tools, better
libraries, better teaching materials, and better techniques. For me:
finally a chance to use C++ as I meant to use it, without being
distracted by standards work and language design concerns. The
important and interesting topic is programming, not programming
languages. I find far too many people belonging to one of two camps:
The ones who think that programming languages are of no importance,
and only get in the way of systems builders (many C programmers are
in this camp), and those who think that a programming language can
perform miracles for them, if only some very specific, language-
technical aspects are "just right.'' (They never are, so all efforts are
expended on designing the perfect programming language.)
Postscript
As this article goes to press, the C++ committee meeting in Stockholm
has already occurred, with generally encouraging results. To answer a
few questions raised by this interview, Bjarne offers this commentary
on the Stockholm meeting:
Many people felt that the large number of issues resolved in Stockholm
-- the library working groups were particularly productive --
necessitated a delay in the vote for CD, since the Working Paper
resulting from the meeting would contain so many changes.
Consequently, the committee didn't vote to submit the (yet to be
composed) document as the CD in Stockholm, but it did vote
unanimously to submit the document produced by incorporating the
Stockholm resolutions and their resulting editorial adjustments as a CD
at the November meeting in Hawaii, without any further technical
changes to the language or library.
What this means for the schedule is not easy to estimate, because that
depends on interlocking schedules of other groups and committees
(such as ANSI and ISO), but estimates vary from none at all to 4
months delay. What matters in my mind is that we -- finally -- know
exactly what the C++ language and standard library consists of.
Naturally, improvements could still be made, but I'm very happy with
what we have now, and it "time to ship." As the saying goes: "the best
is the enemy of the good," and although what we have now isn't
necessarily perfect, it is very good. I'm looking forward to a period of
stability and productivity.
- Bjarne Stroustrup