C++ founding father assesses the language on the eve of its new standard.

WEBINAR:

On-Demand

I know it's a bit early to discuss the farther future of C++ before the C++0x Working Paper is even finalized. Still, what are the next stages in the standardization of C++ that will take place once C++0x has been ratified?

This question reminds me of coming from an 18-hour flight from Los Angeles into the bright morning light in Sydney to be met by the question "What do you think of Australia?" That was my first trip down-under so my total experience of Australia outside the baggage claim area was about two minutes. That's significantly longer than my post-C++0x experience.

We are planning some TR (Technical Reports) and there is some talk about a faster revision cycle (about three years after the standard). The topics for such TRs (or early revision) are:

Library components:

networking (sockets, iostreams over sockets, etc.)

thread pools

file system

lexical_cast

improved I/O (e.g., faster iostreams, memory-mapped I/O)

special mathematical functions

Language features:

modules (including dynamic libraries)

garbage collection (programmer controlled)

And—as usual—a host of little things. I just hope that if the committee takes that path it will not be overwhelmed (distracted) by "little things." As usual, implementations of the library components already exist for experimentation and some (for instance, the networking library) are already in serious commercial use. In particular, see boost.org.

You've been designing and improving C++, along with other devoted members of the standards committee of course, for nearly 30 years. I assume that the addition of templates to C++ in the late 1980 proved to be the most important and successful feature that C++ ever got since you added classes to C in 1979. Is this assumption correct? Is there any C++ feature you regret?

There are things that I would have liked to do better, but who am I to second guess the younger Bjarne? I am no smarter than him and he had a better understanding of the conditions at the time.

In the case of templates, I knew their strengths and I knew their greatest weakness at the time. The first three pages in D&E is a lament for not solving the template argument checking problem. In 1988, I knew the problem, but I don't think anyone knew a solution that would have been viable in the context of the Draconian requirements of flexibility, generality, and performance that were (and are) the bedrock of template use. The design of concepts involved solving genuine research problems; we have papers in POPL and OOPSLA to prove that!

C compatibility has always been a serious problem. The C syntax is horrendous, the conversion rules chaotic, and arrays decay to pointers at the slightest excuse.

These are fundamental and constant problems. However, I chose C compatibility (though never 100 percent compatibility) as a means of making C++ a practical tool rather than yet another pretty language and so we had to live with it. Even today, the overlap between the C and C++ communities and code bases are so large that a serious break of compatibility would simply lead to the language community fragmenting. We have to proceed in the usual way: provide superior alternatives to ugly and/or dangerous features and hope that people use them.

In this respect, I read a Slashdot interview in which you say that you would have anyway started off with an existing programming language as the basis for a new one, as opposed to starting from scratch. Why not start from scratch, really? And why start with C?

Again, I don't have a time machine. At the time, C looked like a good choice for me even though C was not an obvious choice then. My guess is that most people would have chosen something simpler and cleaner, such as Pascal or Modula, over the flexibility and performance of C.

Why not start from scratch? Well, at the time, I decided that to build a useful tool with the skills and resources available, building on an existing language was essential. I wanted a tool, not a beautiful toy. If I had to do a new language, I would again have to evaluate my aims and my resources. Starting from scratch is hard. We always carry our experience with us and anything sufficiently different from the familiar will cause teaching problems. People invariably confuse familiarity with simplicity. Even Java, which was supposedly designed from scratch according to first principles, chose the ugly and illogical C syntax to appeal to C and C++ programmers—and Java doesn't even have the excuse of compatibility. Should I design another language, I guess I would have to try "from scratch" just to get a new set of problems. In that case, I would be very sensitive to the idea that there are other forms of compatibility than source code compatibility, such as link compatibility and source code transformation.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date