Bjarne Stroustrup's FAQ

These are questions that people ask me often. If you have better questions or comments on the answers, feel free to email me bs@research.att.com. Please remember that I can't spend all of my time improving my homepages.

This page concentrates on personal opinions and general questions related to philosophy. For questions that more directly relate to C++ language features and the use of C++, see my C++ style and technique FAQ. For links to useful sources of C++ information, see my C++page. For information about my books (incl. reviews and support information), see my book list. For papers and ISBNs for translations of my books, see my publication list.

Index

How do you pronounce "Bjarne Stroustrup?"
Can I ask you a question?
Why don't you answer your email?
Why don't you make your website look modern?
What is the best book to learn C++ from?
How long does it take to learn C++?
Knowing C is a prerequisite for learning C++, right?
How do I start learning C++?
Will you help me with my homework?
Where can I get a free C++ compiler?
You are Swedish?
What's the best way to improve my C++ programs?
Does it matter which programming language I use?
Did the ANSI/ISO standards committee spoil C++?
When will we have a C++ standard?
Where can I get a machine-readable version of the standard?
Are there any features you'd like to remove from C++?
What will C++0x look like?
When will we have a new ARM?
When will you publish a 4th edition of "The C++ Programming Language"?
Should I buy the "Special Edition" of "The C++ Programming Language"?
What C++ compiler do you recommend? Which libraries?
Is Java the language you would have designed if you didn't have to be compatible with C?
What do you think of C#?
Do you really recommend Ada over C++ for larger projects?
Would you compare C++ to "some language"?
Others do compare their languages to C++; doesn't that annoy you?
You won't compare C++ to other languages, but you write diatribes about C++?
C is better than C++ for small projects, right?
Is C a subset of C++?
What is the difference between C and C++?
When was C++ invented?
Why did you invent C++?
Why did AT&T support the development of C++?
Do you own C++?
Why doesn't C++ have garbage collection?
Why is the code generated for the "Hello world" program ten times larger for C++ than for C?
How can a legacy language like C++ compete with modern, advanced languages?
What is "multiparadigm programming"?
What do you think of EC++?
C++ got its Object-Oriented concepts from Smalltalk?
Is C++ an Object-Oriented language?
Did you really say that?
Did you really give an interview to IEEE?
What is "legacy code"?
Why is the language called C++?
Is the number of C++ users still doubling every year?
Did you expect C++ to become such a success?
What are you working on now?

How do you pronounce "Bjarne Stroustrup?"

It can be difficult for non-Scandinavians. The best suggestion I have heard yet was "start by saying it a few times in Norwegian, then stuff a potato down your throat and do it again :-)" Here is a wav file.

For people who can't receive sound, here is a suggestion: Both of my names are pronounced with two syllables: Bjar-ne Strou-strup. Neither the B nor the J in my first name are stressed and the NE is rather weak so maybe Be-ar-neh or By-ar-ne would give an idea. The first U in my second name really should have been a V making the first syllable end far down the throat: Strov-strup. The second U is a bit like the OO in OOP, but still short; maybe Strov-stroop will give an idea.

Yes, this probably is the most frequently asked question :-)


Can I ask you a question?"

Certainly. I try to answer my email. However, please try to avoid asking a question that is answered in my homepages. Also, please don't rely on a prompt answer. I get a *lot* of email.

Here are links to


Why don't you answer your email?

I do, but I get a lot of email. I estimate that I reply to more than 95% of the messages I receive. However, sometimes I get overwhelmed. Some messages are lost in my mailbox, some are delayed until I can find time, some are delayed until I get around to answering a set of related messages (this often happens to comments about potential errors in my books). Unfortunately, longer and more thoughtful messages are more likely to get delayed than simple ones that have simple answers.

Why don't you make your website look modern?

I'm a "contents provider" not a website designer. I can use my time on improving the contents or the looks, but not both.

What what looks "cool and modern" someone is often considered bad taste by someone else. Also, fashions change fast.

Very plain html downloads and displays faster than anything else, and many people suffer from slow connections to the web.


What is the best book to learn C++ from?

There is no one book that is best for every person. There couldn't be one. People are too different in the way they learn, in what they already know, in what they need, in what they want, and in what kind of effort they are willing to make. For people who are programmers and willing to learn new concepts and techniques from a classical textbook, I recommend The C++ Programming Language (3rd edition). It describes "pure C++," that is, the language independently of any particular software development environment or foundation library (except the standard library, of course). If that is not the right approach for you, there are many other excellent C++ books.

See a note about the structure, contents, and aims of "The C++ Programming Language (3rd edition)": The book is aimed at programmers with some experience and a wish to master C++. It is not aimed at non-programmers trying to learn their first programming language or casual programmers trying to gain a superficial understanding of C++ as fast as possible. Consequently, this book focuses on concepts and techniques and goes to some pain to be complete and precise.

If you want to know why C++ is the way it is, have a look at The Design and Evolution of C++ (D&E). Understanding the design criteria and constraints helps writing better programs.

Have a look at the ACCU (The Association of C and C++ Users) site. This is one of the best sites for book recommendations by experienced programmers who are not afraid to speak their mind (booksellers tend to give rosy reviews, and reviews of the form "This book is perfect, I love it, I have read almost three chapters, and can't wait to read more" are worse than useless - why anyone would take advice on how to learn C++ from someone who completely lacks C++ experience beats me). The ACCU rates books for level of experience required and overall quality.


How long does it take to learn C++?

That depends on what you mean by "learning." If you are a Pascal programmer, you can easily learn enough of the basic types, control structures, and library functions to be effective at what you were effective at using Pascal. Will it take a day or a week? That depends on you and the approach you take. I have seen both and even wider variations. If you are a C programmer you can learn enough C++ to make you more effective at C-style programming in a day.

On the other hand, if you want to be fully comfortable with all the major C++ language constructs, with data abstraction, Object-Oriented programming, generic programming, Object-Oriented design, etc., you can easily spend a year or two - if you aren't already acquainted with those techniques.

Is that then the time it takes to learn C++? Maybe, but then again, that is the timescale we have to consider to become better designers and programmers. If a dramatic change of the way we work and think about building systems isn't our aim, then why bother to learn a new language? Compared to the time required to learn to play the piano well or to become fluent in a foreign (natural) language, learning a new and different programming language and programming style is easy.

For more observations about learning C++ see D&E or a note from comp.lang.c++ that I wrote some time ago.


Knowing C is a prerequisite for learning C++, right?

Wrong. The common subset of C and C++ is easier to learn than C. There will be less type errors to catch manually (the C++ type system is stricter and more expressive), fewer tricks to learn (C++ allows you to express more things without circumlocution), and better libraries available. The best initial subset of C++ to learn is not "all of C".

See Learning Standard C++ as a New Language for a discussion of the choice of C++ constructs, techniques, and libraries for early learning.


Should I learn Smalltalk before C++ to become a real OO programmer?

No. If you want to learn Smalltalk, learn Smalltalk. It is a most interesting language and system, and learning something new is almost always a good idea. However, Smalltalk isn't C++ and writing Smalltalk-style code in C++ is often sub-optimal and frustrating. If you want to become a good C++ programmer and don't have a few months to spare, concentrate on C++ and the concepts it embodies.

How do I start learning C++?

Naturally, that strongly depends on what you already know and your reasons for learning C++. If you are a novice at programming, I strongly recommend that you find an experienced programmer to help you. Otherwise, the inevitable mistakes about language concepts and practical problems with the implementation you use can magnify into serious frustrations.

You'll need a textbook for learning C++. This is the case even when your implementation comes with ample on-line documentation. The reason is that language and library documentation together with sample code are not good teachers of concepts. Typically such sources are silent about why things are the way they are and what benefits you can expect (and which you shouldn't expect) from a technique. Focus on concepts and techniques rather than language-technical details.

When choosing a book, look for one that presents Standard C++ and use the standard library facilities in an integrated manner from the start. For example, reading a string from input should look something like

	string s;	// Standard C++ style
	cin >> s;
and not like this
	char s[MAX];	/* Standard C style */
	scanf("%s",s);
Look for book recommendations from programmers with solid C++ experience. Remember that no one book is the best for everyone. Have a look at the book reviews on the ACCU (The Association of C and C++ Users) site.

Aim to write idiomatic C++: avoid simply writing code in the style of your previous language using C++ syntax; there is little to be gained from simply changing syntax. See Learning Standard C++ as a New Language a discussion of how one might approach C++.


Will you help me with my homework?

No. Sorry. I don't do (other people's) homework. I get too many requests for help with homework and help with finding bugs in student programs to be able to find the time. Anyway, having a distant expert fix your programs is not the best way to learn. Try finding a local person with C++ experience that you can ask for guidance. A good mentor is the best help a student can have; maybe that's why they are not easy to find.

Where can I get a free C++ compiler?

Try Cygwin from RedHat (formerly Cygnus), Djgpp, or Borland5.5. All are aimed at Wintel boxes. These compilers are trying hard for ISO Standards compliance.

For Macs, see Apple.

Caveat: If you want to use "free" compilers for commercial work, be sure to read all legal rules and restrictions attached.

There are a variety of old C++ implementations floating around on the web and on CDs. I do not recommend an old C++ compiler for learning C++ or for new production use. There is little to be gained by fighting your way through bugs that have been fixed years ago or limitations that have been lifted years ago by the standard committee.

For good quality free (parts of) the standard library, see SGI's STL site and STLport.


You are Swedish?

No. I'm Danish. Have a look at my biography.

What's the best way to improve my C++ programs?

I couldn't say. That depends on how you use it. Most people underestimate abstract classes and templates. Conversely, most people seriously overuse casts and macros. Have a look at one of my papers or books for ideas. One way of thinking of abstract classes and templates is as interfaces that allow a more clean and logical presentation of services than is easy to provide through functions or single-rooted class hierarchies.

Does it matter which programming language I use?

Yes, but don't expect miracles. Some people seem to believe that a programming language can or at least should solve most of their problems with system building. They are condemned to search forever for the perfect programming language and become repeatedly disappointed. Others dismiss programming languages as unimportant "implementation details" and put their money into development processes and design methods. They are condemned to program in COBOL, C, and proprietary design languages forever. A good language - such as C++ - can do a lot for a designer and a programmer, as long as its strengths and limitations are clearly understood and respected.

Did the ANSI/ISO standards committee spoil C++?

No. They/we did a good job. You can quibble with details (and I do), but I'm happy with the language and the new standard library. ISO C++ is a better and more coherent language than earlier versions of C++. You can write much more elegant and maintainable C++ programs today than was possible when the standards process started. The new standard library is also a real boon. The provision of strings, lists, vectors, maps, and basic algorithms for such fundamental types makes a major difference to the way one can approach C++. See the library chapters of The C++ Programming Language (3rd edition) (Chapter 3: A Tour of The Standard Library is available electronically) or one of my recent papers.

When will we have a C++ standard?

We have one! The final technical vote took place November 14, 1997, about 10:30am. See a press release from the ISO C++ standards committee. After the technical vote, the standard was ratified by a 22-0 national vote. The standard is ISO/IEC 14882.

This is the language and standard library described in The C++ Programming Language (3rd edition). The C++ compiler and library suppliers are already shipping implementations that are quite close to the draft standard.


Where can I get a machine-readable version of the standard?

The C++ standard (ISO/IEC 14882) is available for downloading at the National Committee for Information Technology Standards Electronic Store. The cost is (as I write this) US$18.00 payable on-line via credit card. The downloaded document is in PDF form, 2794KB total size.

The draft standard as it were in later stages of the standards process can be downloaded for free.

Be warned that the standard is not a tutorial; even expert programmers will do better learning about C++ and new C++ features from a textbook.


Are there any features you'd like to remove from C++?

Not really. People who ask this kind of question usually think of one of the major features such as multiple inheritance, exceptions, templates, or run-time type identification. C++ would be incomplete without those. I have reviewed their design over the years, and together with the standards committee I have improved some of their details, but none could be removed without doing damage.

Most of the features I dislike from a language-design perspective are part of the C subset of C++ and couldn't be removed without doing harm to programmers working under real-world conditions. C++'s C compatibility was a key language design decision rather than a marketing gimmick. Compatibility has been difficult to achieve and maintain, but real benefits to real programmers resulted, and still result today. By now, C++ has features that allows a programmer to refrain from using the most troublesome C features. For example, standard library containers such as vector, list, map, and string can be used to avoid most tricky low-level pointer manipulation.


What will C++0x look like?

I don't know. C++0x will be the outcome of a multi-year standards process that seriously considers the needs of the diverse parts of the C++ community - the discussion about directions for the (2003?, 2005?) revision of the ISO C++ standard is just starting. The C++ standard will remain stable for a long while yet, and the language will remain stable even longer because compatibility is always a major concern.

My personal view is that the key principles should be

The changes and extensions should be chosen to make C++ a better platform for systems programming and library building, and to make C++ easier to teach and learn. Clearly, we will have some discussions about the meaning of "major" in those sentences.

I briefly presented some of my ideas at a panel at SD2001w. Please note that this reflects my personal view of where C++ ought to go rather than committee policy.


When will we have a new ARM?

Ellis&Stroustrup: The Annotated C++ Reference Manual colloquially known as "The ARM" was written in 1989 and was the base of the C++ standards effort. It is by now quite old and does not describe Standard C++.

Andrew Koenig and I are working on a replacement based on the actual text of the ISO standard. This work was delayed because of difficulty in getting permission from ISO to use the actual standards text. (I considered using any other text disloyal to my friends and colleagues on the standards committees and a disfavor to the C++ community). Our work on this "ARM++" has been delayed (again), so I don't dare give an estimate of when it will become available.


When will you publish a 4th edition of "The C++ Programming Language"?

There won't be a need until 2004 or so. The definition of C++ and the fundamental techniques that it supports are unlikely to change significantly before then. When I write, I aim for a long "shelf life" and the ISO C++ standard ensures basic stability. In this context, it is important that The C++ Programming Language (3rd Edition) describes Standard C++, its standard library, and the techniques they support rather than some particular implementation and some proprietary library. Minor changes and additions I deal with through "online maintenance" and minor improvements to new printings of the book; see my errata.

For 2000 printings - including the hardcover "special edition" - I have two new appendices on Locales and Standard-Library Exception Safety.

The German translation of the "Special Edition" is referred to as the 4th edition.


Should I buy the "Special Edition" of "The C++ Programming Language"?

Sure , buy it early and often :-)

Seriously, the difference between the current printings of the special edition and the 3rd edition is just the hard cover (and the price difference implied by that stronger cover).

If I were a C++ programmer who hadn't read The C++ Programming Language (3rd Edition), I'd buy and read either the 3rd edition or the special edition. If I used my textbooks and references heavily, I'd choose the hard cover. The cover on the 3rd is the best soft cover available, but it doesn't equal the special edition's hard cover.

If I already had the 3rd edition, I'd buy the SE if my current copy were fraying or if my copy were an early printing.

Compared to the first printing, the special edition and the most recent printings of the 3rd edition have about 1,000 corrections and clarifications. As a heavy C++ user, I find that significant. There are also the two new appendices (just over 100 pages; available for download: Locales and Standard-Library Exception Safety).

Existing material has not moved around so page numbers can be used to refer to material in old printings, new printings of the 3rd edition, and in the SE.

The SE also has an improved index.


What C++ compiler do you recommend? Which libraries?

I don't recommend. It wouldn't be fair. However, do get a recent release. Naturally, newer compilers approximate the ISO standard much more closely than compilers from a few years ago.

Also, where possible, prefer the standard library to non-standard "foundation libraries" and try to minimize use of proprietary extensions.


Is Java the language you would have designed if you didn't have to be compatible with C?

No. Java isn't even close. If people insist on comparing C++ and Java - as they seem to do - I suggest they read The Design and Evolution of C++ (D&E) to see why C++ is the way it is, and consider both languages in the light of the design criteria I set for C++. Those criteria will obviously differ from the criteria of Sun's Java team. Despite the syntactic similarities, C++ and Java are very different languages. In many ways, Java seems closer to Smalltalk than to C++.

Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation-dependent extensions or libraries. That is the way every commercially successful language has developed. Just look at any language you consider successful on a large scale. I know of no exceptions, and there are good reasons for this phenomenon.

(The paragraph above was written before Java1.1. I confidently predict that Java will acquire a template-like mechanism and improved support for concrete types. It simply has to do that to be reasonably complete. In addition, it will also undergo many minor changes - mostly extensions. Later still (fall 1998), I found a proposal from James Gosling for adding concrete types, operator overloading, and support for numeric computation to Java: The Evolution of Numerical Computing in Java and a debunking of some Java myths by W. Kahan, UC Berkeley, One of the world's leading numerical analysts: How Java's Floating-Point Hurts Everyone Everywhere).

I find most of the Java advertising on TV and in print inaccurate and offensive. Denouncing all code written in languages other than Java as "contamination" is insulting to programmers. Suggesting that all "legacy code" should be rewritten in Java is wildly unrealistic and irresponsible. Sunsoft and its followers seem to consider this kind of bombast necessary to fight "the evil empire of Microsoft" but insults and hype simply drives programmers who prefer to use a variety of programming languages into the arms of Microsoft.

Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation. It has been pointed out that you can write programs in any language for the JVM and associated operating systems facilities. However, the JVM, etc., are heavily biased in favor of Java. It is nowhere near being a general reasonably language-neutral VM/OS.

Personally, I'll stick to reasonably portable C++ for most of the kind of work I think most about and use a variety of languages for the rest.


What do you think of C#?

I have no comments on C# as a language. It will take a lot to persuade me that the world needs yet another proprietary language (YAPL). It will be especially hard to persuade me that it needs a language that is closely integrated with a specific proprietary operating system.

Clearly, I'm no great fan of proprietary languages, and quite a fan of open, formal standards.


Do you really recommend Ada over C++ for larger projects?

No. I have no idea who started that rumor, but it must have been an over-enthusiastic or malicious Ada devotee.

Would you compare C++ to "some language"?

No, sorry, I won't. You can find the reason in the introductory notes of The Design and Evolution of C++:

"Several reviewers asked me to compare C++ to other languages. This I have decided against doing. Thereby, I have reaffirmed a long-standing and strongly held view: Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness. I do not have the time, and as the designer of C++, my impartiality would never be fully credible.

I also worry about a phenomenon I have repeatedly observed in honest attempts at language comparisons. The authors try hard to be impartial, but are hopelessly biased by focusing on a single application, a single style of programming, or a single culture among programmers. Worse, when one language is significantly better known than others, a subtle shift in perspective occurs: Flaws in the well-known language are deemed minor and simple workarounds are presented, whereas similar flaws in other languages are deemed fundamental. Often, the workarounds commonly used in the less-well-known languages are simply unknown to the people doing the comparison or deemed unsatisfactory because they would be unworkable in the more familiar language.

Similarly, information about the well-known language tends to be completely up-to-date, whereas for the less-known language, the authors rely on several-year-old information. For languages that are worth comparing, a comparison of language X as defined three years ago vs. language Y as it appears in the latest experimental implementation is neither fair nor informative. Thus, I restrict my comments about languages other than C++ to generalities and to very specific comments."

That said, I consider C++ the best choice in programming language for a wide variety of people and applications.


Others do compare their languages to C++; doesn't that annoy you?

It does when it is done incompetently or for commercial gain. The most widely circulated comparisons tend to be those written by proponents of some language, Z, to prove that Z is better that other languages. Given its wide use, C++ is often top of the list of languages that the proponents of Z wants to prove inferior. Often, such papers are "published" or distributed by a company that sells Z as part of a marketing campaign. Surprisingly, many seem to take an unreviewed paper written by people working for a company selling Z "proving" that Z is best seriously. One problem is that there are always grains of truth in such comparisons. After all, no language is better than every other in all possible ways. C++ certainly isn't perfect, but selective truth can be most seductive and occasionally completely misleading.

When looking at a language comparison consider who wrote it, consider carefully if the descriptions are factual and fair, and also if the comparison criteria are themselves fair for all languages considered. This is not easy.


You won't compare C++ to other languages, but you write diatribes about C++?

I don't write diatribes (that's a hostile characterization of some text), but I do consider it reasonable - possibly even a duty - for someone who designed a language to explain its virtues and defend it against hostile characterizations. Often, I also point out the limitations of C++ and the fundamental assumptions of the design of C++ (for example, see D&E).

C is better than C++ for small projects, right?

Not in my opinion. I never saw a project for which C was better than C++ for any reason but the lack of a good C++ compiler.

Is C a subset of C++?

In the strict mathematical sense, C isn't a subset of C++. There are programs that are valid C but not valid C++ and even a few ways of writing code that has a different meaning in C and C++. However, C++ supports every programming technique supported by C. Every C program can be written in essentially the same way in C++ with the same run-time and space efficiency. It is not uncommon to be able to convert tens of thousands of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985.

Well written C tends to be legal C++ also. For example, every example in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" is also a C++ program.

Examples of C/C++ compatibility problems:

int main()
{
	double sq2 = sqrt(2);   /* Not C++: call undeclared function */
	int s = sizeof('a');    /* silent difference: 1 in C++ sizeof(int) in C */
}
Calling an undeclared function is poor style in C and illegal in C++. So is passing arguments to a function using a declaration that doesn't list argument types:
void f();	/* argument types not mentioned */

void g()
{
	f(2);	/* poor style C. Not C++ */
}
In C, a void* can be implicitly converted to any pointer type, and free-store allocation is typically done using malloc() which has no way of checking if "enough" memory is requested:
void* malloc(size_t);

void f(int n)
{
	int* p = malloc(n*sizeof(char));  /* not C++. In C++, allocate using `new' */
	char c;
	void* pv = &c;
	int* pi = pv;   /* implicit conversion of void* to int*. Not in C++ */
}
Note the potential alignment error caused by the implicit conversion of the void* to a int*.

When converting from C to C++, beware that C++ has more keywords than C:

int class = 2;    /* ok in C. Syntax error in C++ */
int virtual = 3;  /* ok in C. Syntax error in C++ */
Except for a few examples such as the ones shown above (and listed in detail in the C++ standard and in Appendix B of
The C++ Programming Language (3rd Edition)), C++ is a superset of C. (Appendix B is available for downloading).

What is the difference between C and C++?

C++ is a direct descendant of C that retains almost all of C as a subset. C++ provides stronger type checking than C and directly supports a wider range of programming styles than C. C++ is "a better C" in the sense that it supports the styles of programming done using C with better type checking and more notational support (without loss of efficiency). In the same sense, ANSI C is a better C than K&R C. In addition, C++ supports data abstraction, object-oriented programming, and generic programming (see The C++ Programming Language (3rd Edition)"; Appendix B discussing compatibility issues is available for downloading).

I have never seen a program that could be expressed better in C than in C++ (and I don't think such a program could exist - every construct in C has an obvious C++ equivalent). However, there still exist a few environments where the support for C++ is so weak that there is an advantage to using C instead.

For a discussion of the design of C++ including a discussion of its relationship with C see The Design and Evolution of C++.


When was C++ invented?

I started work on what became C++ in 1979. The initial version was called "C with Classes". The first version of C++ was used internally in AT&T in August 1983. The name "C++" was used late that year. The first commercial implementation was released October 1985 at the same time as the publication of the 1st edition of The C++ Programming Language. Templates and exception handling were included later in the 1980's and documented in The Annotated C++ Reference Manual and The C++ Programming Language (2rd Edition).

The current definition of C++ is The ISO C++ Standard described in The C++ Programming Language (3rd Edition).

You can find a more complete timeline and more detailed explanations in The Design and Evolution of C++.


Why did you invent C++?

I wanted to write efficient systems programs in the styles encouraged by Simula67. To do that, I added facilities for better type checking, data abstraction, and object-oriented programming to C. The particular projects that prompted this work had to do with distributing operating system facilities across a network. The more general aim was to design a language in which I could write programs that were both efficient and elegant. Many languages force you to choose between those two alternatives.

The specific tasks that caused me to start designing and implementing C++ (initially called "C with Classes") had to do with the design of a distributed operating system.

You can find more detailed explanations in The Design and Evolution of C++.


Why did AT&T support the development of C++?

AT&T builds systems of greater complexity and with greater reliability requirements than most organizations. Consequently, we have to influence the market and help set standards that meet our needs - or else we won't have the tools to build our systems. Left to itself "the industry" will create languages and tools for dealing with "average" problems. Similarly, teachers tend to focus on languages and tools that serve students and researchers well - even if they don't scale to the most demanding tasks.

At the time where I developed C++ - and before that when Ken Thompson and Dennis Ritchie developed Unix and C - AT&T was probably the worlds largest civilian user of (and consumer of) software tools. Then, we probably used a wider range of systems - from the tiniest embedded processors to the largest supercomputers and data-processing systems. That put a premium on systems that were applicable in many technical cultures and on many platforms. C and C++ were designed with such demands in mind.

Thus generality is essential, and proprietary features are seen as limiting the choice of platforms and vendors. As a consequence AT&T was and is a major supporter of formal standards (for example, ISO C and ISO C++).

Actually, AT&T made enough money on Cfront, my original C++ compiler, to pay for the development of C++ several times over.


Do you own C++?

No. If anyone "owns C++," it must be the ISO. AT&T gave the rights to the C++ manual that I wrote to ISO. The ISO C++ Standard is copyrighted by ISO.

Compiler vendors do not pay royalties to me or to AT&T for C++, and ISO standards are specifications intended for royalty-free use by everyone (once they have paid the ISO or a national standard committee for their copy of the standard).


Why doesn't C++ have garbage collection?

If you want automatic garbage collection, there are good commercial and public-domain garbage collectors for C++. For applications where garbage collection is suitable, C++ is an excellent garbage collected language with a performance that compares favorably with other garbage collected languages. See The C++ Programming Language (3rd Edition) for a discussion of automatic garbage collection in C++. See also, Hans-J. Boehm's site for C and C++ garbage collection.

Also, C++ supports programming techniques that allows memory management to be safe and implicit without a garbage collector.


Why is the code generated for the "Hello world" program ten times larger for C++ than for C?

It isn't on my machine, and it shouldn't be on yours. In fact, the object code for the C++ version of the "hello world" program is smaller than the C version on my machine. There is no language reason why the one version should be larger than the other. It is all an issue on how the implementor organized the libraries. If one version is significantly larger than the other, report the problem to the implementor of the larger.

How can a legacy language like C++ compete with modern, advanced languages?

Naturally, caling C++ a legacy language shows a bias (see legacy code). That aside, people are usually thinking of Java or C# when they ask such a question. I will not compare C++ to those language, but I can point out that "modern" doesn't necessarily mean "better", and that both Java and C# are rooted in 1980s style OOP to an even greater extent than early C++ was.

Since 1987 or so, the focus of development the C++ language and its associated programming styles have been the use of templates, static polymorphism, generic programming, and multiparadigm programming. This is way beyond the scope of the much-hyped proprietary languages. Another key difference is that C++ supports user-defined types to the same extent as built-in types. This - especially in combination with the use of templates, constructors, and destructors - enables the C++ programmer to use programming and design techniques that (IMO) are more advanced than what is supported in the languages with which C++ is most often compared.

Standard C++ and the design and programming styles it supports owe a debt to the functional languages, especially to ML. Early variants of ML's type deduction mechanisms were (together with much else) part of the inspiration of templates. Some of the more effective functional programming techniques were part of the inspiration of the STL and the use of function objects in C++. On the other hand, the functional community missed the boat with object-oriented programming, and few of the languages and tools from that community benefitted from the maturing experience of large-scale industrial use.

Clearly, I don't think that garbage collection is the sole defining characteristic of "advanced" in the context of programming languages. In particular, note that C++ provides support for effective and efficient memory management techniques that can eliminate resource leaks without the use of a garbage collector. If you disagree, you can just start using a garbage collector for C++; there are good ones available.


What is "multiparadigm programming"?

Multiparadigm programming is a fancy way of saying "programming using more than one programming style, each to its best effect." For example, using object-oriented programming when run-time resolution between different object types is required and generic programming when static type safety and run-time performance is at a premium. Naturally, the main strength of multiparadigm programming is in programs where more than one paradigm (programming style) is used, so that it would be hard to get the same effect by composing a system out of parts written in languages supporting different paradigms. I find the most compelling cases for multiparadigm programming are found where techniques from different paradigms are used in close collaboration to write code that is more elegant and more maintainable than would be possible within a single paradigm. A simple example is the traversal of a statically typed container of objects of a polymorphic type:
	void draw_all(vector< Shape*>& vs)	// draw each element of a standard vector
	{
		for_each(vs.begin(),vs.end(),mem_fun(&Shape::draw));
	}
Here, Shape* will be an abstract base class defining the interface to a hierarchy of geometric shapes. This example easily generalizes to any standard library container:
	template< class C> void draw_all(C& cs)	// draw each element of a standard container
	{
		for_each(cs.begin(),cs.end(),mem_fun(&Shape::draw));
	}

Jim Coplien's book "Multiparadigm Design for C++" (Addison Wesley, 1998) explores the use of multiple paradigms in the context of design and design methods.


What do you think of EC++?

EC++ is an (almost) subset of C++ lacking exceptions, templates, namespaces, RTTI support, multiple inheritance, etc. being defined by an "industry consortium." I am not in favor of language subsets or dialects. I am especially not fond of subsets that cannot support the standard library so that the users of that subset must invent their own incompatible foundation libraries. I fear that a defined subset of C++ could split the user community and cause acrimony (3/31/1999: I just saw an advertisement that used vivid graphics to indicate how EC++ reduced "fat" (i.e. memory space) by abolishing - among other things - namespaces, templates, and C++ standard strings. Sigh). I strongly prefer work on "standards" to occur in an open forum (such as ISO or a national standards organization).

I do not think that a defined subset or dialect of C++ is necessary for embedded systems programming (see my keynote at the Spring'99 Embedded Systems Conference). The embedded systems programming community would be better served by a group considering and documenting how the needs of the embedded systems community relates to C++. Different projects and organizations would then have a rational basis for their decisions of what part of C++ to use. The embedded systems community is diverse. Many currently rely on templates, some are using exceptions, and namespaces have no implications on the size or speed of programs. Only the language and library defined by the ISO C++ standard is flexible, general, and well-defined enough to serve the embedded systems community for the decades to come. In the relatively few cases where run-time space or efficiency is a problem with Standard C++ (usually because of sub-optimal implementations) a few compiler switches can help the optimizer (e.g. for some projects and for some compilers disabling exceptions may yield significant performance benefits - and sometimes it will not).


C++ got its Object-Oriented concepts from Smalltalk?

No. C++ got the key notions of classes, derived classes, virtual functions (in other words, the notions of encapsulation, inheritance and polymorphism) from Simula just like Smalltalk did. In terms of family relationships, C++ and Smalltalk are siblings.

Is C++ an Object-Oriented language?

C++ is a multi-paradigm language that supports Object-Oriented and other useful styles of programming. If what you are looking for is something that forces you to do things in exactly one way, C++ isn't it. There is no one right way to write every program - and even if there were there would be no way of forcing programmers to use it.

That said, writing C-style programs in C++ is for most applications not an optimal use of C++. To be a really effective C++ programmer, you must use the abstraction mechanisms and the type system in a way that fits reasonably with their intent. Trying to ignore or defeat the C++ type system is a most frustrating experience.

Writing Smalltalk-style in C++ can be equally frustrating and sub-optimal as writing C-style code in C++.


Did you really say that?

Yes, I did say something along the lines of "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." What people tend to miss, is that what I said there about C++ is to a varying extent true for all powerful languages. As you protect people from simple dangers, they get themselves into new and less obvious problems. Someone who avoids the simple problems may simply be heading for a not-so-simple one. One problem with very supporting and protective environments is that the hard problems may be discovered too late or be too hard to remedy once discovered. Also, a rare problem is harder to find than a frequent one because you don't suspect it.

Did you really give an interview to IEEE?

in which you confessed that C++ was deliberately created as an awful language for writing unmaintainable code to increase programmers' salaries?

Of course not. Read the real IEEE interview.


What is "legacy code"?

"Legacy code" is a term often used derogatorily to characterize code that is written in a language or style that (1) the speaker/writer consider outdated and/or (2) is competing with something sold/promoted by the speaker/writer. "Legacy code" often differs from its suggested alternative by actually working and scaling.

Why is the language called C++?

For the first few years, I called my language ``C with Classes.'' However people had taken to calling C with Classes ``new C,'' and then C. This abbreviation led to C being called ``plain C,'' ``straight C,'' and ``old C.'' The last name, in particular, was considered insulting, so common courtesy and a desire to avoid confusion led me to look for a new name. I picked C++ because it was short, had nice interpretations, and wasn't of the form ``adjective C.'' In C, ++ can, depending on context, be read as ``next,'' ``successor,'' or ``increment,'' though it is always pronounced ``plus plus.'' The name C++ and its runner up ++C are fertile sources for jokes and puns - almost all of which were known and appreciated before the name was chosen. The name C++ was suggested by Rick Mascitti. It was first used in December of 1983.

There have been at least a dozen languages called D. See D&E for more name trivia.


Is the number of C++ users still doubling every year?

No. During 1980-1991, the number of users doubled every seven and a half months (see The Design and Evolution of C++). However, there simply aren't enough programmers to sustain that. From the few numbers I can get (compiler sales, book sales, workloads of consultants I happen to know, IDS, etc.), I estimate that the growth rate is about five to ten percent. Steady and definitely positive. IDS estimated that 1.2 million C++ Implementations were sold in 1996.

Did you expect C++ to become such a success?

Of course not. The success rate for general-purpose programming languages is vanishing small. I knew that, and I knew that the chance of success was affected by marketing clout, which I did not have.

C++ was initially designed and implemented as a set of general facilities addressing some specific problems that I and my colleagues faced. The generality - and efficiency - of the facilities provided turned out to serve much wider needs than I had anticipated. The emphasis on general facilities - as opposed to the provision of specific solutions to specific problems - has remained with C++ and has served its community well as the specific problems facing the community have changed over the years.


What are you working on now?

A better FAQ :-)

Seriously, I'm looking for fundamental ways of improving the tools and techniques we use to build large real-world systems.

 

 HOME PAGE