Menu
The A-Z of Programming Languages: C++

The A-Z of Programming Languages: C++

Bjarne Stroustrup of C++ fame dissects the history of his famed programming language

Were there any particularly difficult or frustrating problems you had to overcome in the development of the language?

Lots! For starters, what should be the fundamental design rules for the language? What should be in the language and what should be left out? Most people demand a tiny language providing every feature they have ever found useful in any language. Unfortunately, that's impossible.

After a short period of relying on luck and good taste, I settled on a set of "rules of thumb" intended to ensure that programs in C++ could be simultaneously elegant (as in Simula67, the language that introduced object-oriented programming) and efficient for systems programming (as in C). Obviously, not every program can be both and many are neither, but the intent was (and is) that a competent programmer should be able to express just about any idea directly and have it executed with minimal overheads (zero overheads compared to a C version).

Convincing the systems programming community of the value of type checking was surprisingly hard. The idea of checking function arguments against a function declaration was fiercely resisted by many - at least until C adopted the idea from C with Classes.

These days, object-oriented programming is just about everywhere, so it is hard for people to believe that I basically failed to convince people about it's utility until I finally just put in virtual functions and demonstrated that they were fast enough for demanding uses. C++'s variant of OOP was (and is) basically that of Simula with some simplifications and speedups.

C compatibility was (and is) a major source of both problems and strengths. By being C compatible, C++ programmers were guaranteed a completeness of features that is often missing in first releases of new languages and direct (and efficient) access to a large amount of code - not just C code, but also Fortran code and more because the C calling conventions were simple and similar to what other languages supported. After all, I used to say, reuse starts by using something that already exists, rather than waiting for someone developing new components intended for reuse. On the other hand, C has many syntactic and semantic oddities and keeping in lockstep with C as it evolved has not been easy.

What are the main differences between the original C with Classes and C++?

Most of the differences were in the implementation technique. C with Classes was implemented by a preprocessor, whereas C++ requires a proper compiler (so I wrote one). It was easy to transcribe C with Classes programs into C++, but the languages were not 100% compatible. From a language point of view, the major improvement was the provision of virtual functions, which enabled classical object-oriented programming. Overloading (including operator overloading) was also added, supported by better support for inlining. It may be worth noting that the key C++ features for general resource management, constructors and destructors, were in the earliest version of C with Classes. On the other hand, templates (and exceptions) were introduced in a slightly later version of C++ (1989); before that, we primarily used macros to express generic programming ideas.

Would you have done anything differently in the development of C++ if you had the chance?

This common question is a bit unfair because of course I didn't have the benefits of almost 30 years of experience with C++ then, and much of what I know now is the result of experimentation with the earlier versions of C++. Also, I had essentially no resources then (just me - part time) so if I grandly suggest (correctly) that virtual functions, templates (with "concepts" similar to what C++0x offers), and exceptions would have made C++85 a much better language, I would be suggesting not just something that I didn't know how to design in the early 1980s but also something that - if I magically had discovered the perfect design - couldn't have been implemented in a reasonable time.

I think that shipping a better standard library with C++ 1.0 in 1985 would have been barely feasible and would have been the most significant improvement for the time. By a "better library" I mean one with a library of foundation classes that included a slightly improved version of the (then available and shipping) task library for the support of concurrency and a set of container classes. Shipping those would have encouraged development of improved versions and established a culture of using standard foundation libraries rather than corporate ones.

Later, I would have developed templates (key to C++ style generic programming) before multiple inheritance (not as major a feature as some people seem to consider it) and emphasized exceptions more. However, "exceptions" again brings to a head the problem of hindsight. Some of the most important concepts underlying the modern use of templates on C++ did not exist until a bit later. For example the use of "guarantees" in describing safe and systematic uses of templates was only developed during the standardization of C++, notably by Dave Abrahams.


Follow Us

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags a-z of programming languages

Events

Show Comments